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SUMMARY 


This  Small  Business  Innovation  Research  (SBIR)  study  was 
initiated  under  Contract  No.  F19628-87-C-0254  to  review  and 
refine  a  concept  called  the  Automated  Tactical  Aircraft  Launch 
and  Recovery  System  (ATALARS).  The  major  product  is  a 
specification  for  a  proof  of  concept  demonstration  which  consists 
of  two  parts:  this  report  and  a  model  of  the  demonstration 
scenario  capable  of  being  run  on  ACSI's  Enhanced  JTIDS  System 
Exerciser  (EJSE). 

ACSI  has  made  a  preliminary  investigation  of  the  potential  use  of 
ATALARS  as  the  solution  to  the  Air  Traffic  Control  (ATC) 
requirements  of  the  year  2000  and  beyond.  During  this  study, 

ACSI  has  begun  to  refine  the  ATALARS  concept  and  has  specified 
how  a  proof  of  concept  demonstration  could  be  performed  during 
Phase  II,  by  modifying  subsystems  of  ACSI's  currently  available 
Enhanced  JTIDS  System  Exerciser. 


The  results  of  the  study  are  described  in  the  following  pages. 
The  study  shows  that  the  Joint  Tactical  Information  Distribution 
System  (JTIDS)  can  perform  as  the  ATALARS  data  link  and  can 
provide  much  of  the  desired  indirect  surveillance  in  a  tactical 
environment.  Further,  ACSI  has  determined  that  implementing  a 
subset  of  ATC  algorithms  on  the  EJSE  can  provide  an  effective 
proof  of  concept  demonstration  in  a  simulated  real-time 
environment.  ACSI  can  perform  this  proof  of  concept 


demonstration  as  a  SBIR  Phase  II  effort. 
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1.0  INTRODUCTION 

1.1  ATALARS  Concept. 

The  ATALARS  concept  envisions  a  radical  change  in  the  manner  in 
which  air  traffic  control  is  performed.  In  lieu  of  the 
conventional  voice  and  radar  based  systems,  ATALARS  proposes  the 
use  of  indirect  surveillance,  an  automatic  data  link  and 
automated  management  and  control  to  provide  the  following 
services : 

1.  Area  Airspace  Management 

2.  Approach  Control 

3.  Landing  Control 

4.  Departure  Control 

5.  Information  Advisories 

6.  Tactical  System  Interoperability 

As  its  name  implies,  the  emphasis  of  ATALARS  is  on  activity  in 
the  terminal  environment.  However,  due  to  the  close  proximity 
and  number  of  airfields  in  some  of  the  areas  where  ATALARS  will 
be  used,  it  will  have  to  be  able  to  manage  all  ATC  activity  in 
its  assigned  airspace. 

The  ATALARS  concept  is  described  in  detail  in  a  paper  titled 
"Advanced  Air  Traffic  Control  Concept"  ( ESD-TR-86-259 )  by  St. 
Sauveur  and  Hughes,  dated  19  June  1986.  A  diagram  showing  the 
major  components  of  the  ATALARS  concept  and  their 
interrelationships  is  shown  in  figure  1. 

1.2  Technical  Objectives. 

In  the  proposal  for  Phase  I,  four  technical  objectives  were 
set  for  this  effort.  They  were  reviewed  and  affirmed  at  the 
outset  of  the  study,  and  are  listed  below: 

1.  Define  at  least  a  subset  of  the  algorithms/rules 
required  to  support  an  automated  ATC  capability  for  a 
single  ATALARS  Ground  Control  Unit  (GCU). 

2.  Define  the  data  set  communications  requirements 
(information  contents)  required  to  support  an  automated 
ATC  capability.  These  will  be  defined  in  terms  of 
specified  JTIDS  messages. 


( ATALARS. TX/317C] 


-1- 


Precision  Position 
Location  (GPS) 


E-3AWACS(  A 
(Indirect  Surveillance) 


JTIDS  Network 


Position  &  Status 
Reporti  ng 


Position  &  Status 
Reporting 


Approach  Control 


Data  Link: 
Commands  to 
Controlled 
Aircraft 

V  * 

\Data  From 
\  Network 


Local  Control 
(Precision  Landing 
Aids) 


Airfield 


ATALARS  GCU 


-2- 


ATALARS  PHASE  1  BKPOBT 
MARCH  1988 


3.  Identify  the  modifications  to  the  EJSE  required  to 
support  a  demonstration  of  the  automated  ATC  capability 
in  accordance  with  the  algorithms/rules  and 
communication  requirements  defined  above. 

4.  Define  a  Preliminary  Operational  Scenario  which  will 
form  the  basis  for  simulation  and  test  in  the  SBIR 
Phase  II  study. 

Although  this  study  addressed  most  of  the  ATALARS  services,  the 
emphasis  was  on  the  decision  aids  to  be  employed  in  the  GCU 
computer  (referred  to  as  the  "ATALARS  Processor"  in  this  report) 
and  on  the  extent  to  which  the  JTIDS  data  link  can  support  the 
ATALARS  services.  As  a  result,  precision  landing  aids  such  as 
the  Microwave  Landing  System  (MLS),  and  other  navigation  aids 
which  would  support  indirect  surveillance,  such  as  the  Global 
Positioning  System  (GPS),  were  not  covered  in  any  depth. 

1 . 3  Study  Approach . 

The  original  work  plan  for  this  study  envisioned  the  linear 
sequence  of  activities  shown  in  figure  2,  a  schedule  prepared  in 
August,  1987,  before  the  contract  was  awarded.  As  the  study 
evolved,  however,  tasking  followed  much  more  of  an  iterative  path 
than  a  sequential  one.  These  iterations  were  strongly  driven  by 
the  demonstration  scenario  development.  Analyzing  the  real  time 
activities  of  aircraft  under  simulated  ATALARS  control 
highlighted  the  information  that  needed  to  be  exchanged. 

Further,  since  the  EJSE  is  designed  to  be  a  JTIDS  network 
participant,  the  JTIDS  message  requirements  for  ATALARS  were 
quickly  identified,  because  the  messages  are  the  most  readily 
available  vehicle  for  information  exchange  between  controlled 
aircraft  and  the  ground  controller.  Finally,  even  the  process  of 
identifying  the  ATALARS  algorithms  became  easier  when  analysts 
could  assess  situations  which  would  evolve  on  the  EJSE. 

Another  difference  in  the  actual  conduct  of  the  study  was  that 
the  modifications  required  for  the  EJSE  to  perform  the  proof  of 
concept  demonstration  were  apparent  from  the  start,  so  this  part 
of  the  study  was  able  to  be  done  on  a  parallel  path.  The  revised 
and  approved  schedule,  shown  in  figure  3,  reflects  the  changes  in 
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task  sequence. 

Since  the  primary  intent  of  this  study  was  to  specify  a  proof  of 
concept  demonstration,  one  of  ACSI's  first  objectives  was  to 
narrow  the  focus  of  the  study  to  deal  with  a  specific  aspect  of 
Air  Traffic  Control.  The  intent  was  to  select  an  aspect  of  ATC 
which  would  provide  highly  visible  results  when  demonstrated 
during  the  SBIR  Phase  II  activity,  so  it  would  be  clear  to  anyone 
observing  the  demonstration  that  the  model  ATALARS  Processor  was 
working.  Initially,  the  collision  avoidance  aspects  of  the  Ar*=>-> 
Airspace  Management  service  seemed  to  present  the  best 
opportunity  to  do  this.  A  scenario  could  be  set  up  which  would 
result  in  a  collision  if  left  to  run  as  started,  but  when  the 
simulated  GCU  was  activated,  it  would  vector  the  two  aircraft 
that  are  on  a  collision  course  to  safe  headings  and/or 
altitudes.  Although  this  capability  will  be  included  in  the 
Phase  II  demonstration,  it  became  apparent  during  the 
study/investigation  that  collision  avoidance  may  not  be  a  major 
concern  for  the  ATALARS  Ground  Control  Unit  after  the  year  2000. 
With  the  indirect  surveillance  and  automatic  data  link 
capabilities  implicit  in  the  ATALARS  concept,  and  on  board 
support  systems  such  as  the  "Pilot's  Associate"  being  developed 
for  the  Advanced  Tactical  Fighter,  each  aircraft  would  have  a 
cockpit  display  which  would  warn  its  pilot  of  the  impending 
danger  and  recommend  a  course  of  action,  thus  allowing  the  pilots 
themselves  to  take  evasive  action  without  any  inputs  from  the 
Ground  Control  Unit.  However,  the  Ground  Control  Unit  would 
retain  an  active  role  in  highly  constrained  or  congested  airspace 
as  well  as  in  situations  where  one  or  both  aircraft  are  not 
equipped  with  the  ATALARS  data  link. 

The  next  choice  for  demonstration  of  the  concept  was  Landing 
Control.  Although  not  as  dramatic  as  collision  avoidance,  it  did 
provide  interaction  between  the  Ground  Control  Unit  and  the 
aircraft.  As  the  study  proceeded  and  work  began  to  identify  and 
define  a  set  of  algorithms  and  rules  for  providing  the  ATC 
Landing  Control  cervices,  it  was  found  that  decreasing  the  area 
under  control  produced  simulation  results  exactly  opposite  to 
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what  were  hoped  for.  Limiting  the  analysis  to  final  approach  and 
landing  produced  results  which  were  "quick  and  jerky"  and  not 
reflective  of  true  aircraft  operations.  This  is  because  the 
small  distances  involved  caused  radical  changes  to  the  simulated 
aircraft's  motion  when  correcting  even  minor  deviations  from  the 
planned  route.  Also,  it  was  found  that  indirect  surveillance  and 
the  automatic  data  link  capability  currently  provided  by  JTIDS 
may  be  insufficient  by  themselves  to  land  an  aircraft  in 
conditions  where  the  pilot  has  no  visibility.  A  pilot  cannot 
proceed  past  the  Missed  Approach  Point  to  touchdown  by  following 
instructions  to  go  from  point  to  point  as  they  are  received  over 
a  data  link.  Therefore,  the  focus  of  the  study  was  expanded  to 
cover  Approach  Control  and  the  Approach  Control  aspects  of  Area 
Airspace  Management,  Landing  Control  and  Information  Advisories, 
which  were  found  to  comprise  a  major  share  of  the  controller's 
workload . 

To  accomplish  this  study,  ACSI  assembled  an  ATALARS  research  team 
consisting  of  a  small  nucleus  of  people  who  are  highly  capable  in 
the  fields  of  interest.  First  were  pilots  and  people  with 
related  ATC  experience.  They  provided  their  experience  and 
guidance  in  establishing  an  initial  set  of  the  rules/algorithms 
required  for  demonstrating  the  ATC  functions  of  the  ATALARS 
concept.  In  addition,  they  defined  the  information  needed  by  the 
pilot  and  by  the  Ground  Control  Unit  for  subsequent  comparison  to 
the  JTIDS  message  set.  The  next  group  was  the  operations 
analysts  who  created  the  scenario  and  performed  the  comparison  of 
information  required  to  what  is  available  in  the  JTIDS  Tactical 
Data  Information  Link  (TADII.-J)  Technical  Interface  Design  Plan 
(TIDP).  The  last  group  wa  the  systems  engineers  who  worked  on 
the  ATALARS  concept  and  established  the  approach  for  the  proof  of 
concept  demonstration  on  the  EJSE. 
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2 . 0  STUDY  RESULTS 

This  section  describes  the  results  of  ACSI's  Phase  I  ATALARS 
study.  They  are  arranged  in  the  same  sequence  as  the  technical 
objectives  described  earlier: 

1 .  ATALARS  Algorithms 

2.  Data  Set  Communications  Requirements 

3.  EJSE  Utilization  for  Proof  of  Concept  Demonstration 

4.  Scenario 

2 . 1  ATALARS  Algorithms 

2.1.1  Introduction.  The  identification  and  quantification  of 
the  rules,  algorithms  and  data  needed  to  automate  ATC  functions 
proved  to  be  the  most  time  consuming  part  of  the  study.  First 
was  the  issue  of  complexity.  At  one  extreme,  a  properly  briefed 
pilot  who  has  filed  a  flight  plan  and  is  flying  a  properly 
instrumented  aircraft  can  complete  a  flight  with  virtually  no 
interaction  with  the  ATC.  At  the  other  extreme  is  the  situation 
faced  by  ATC  in  a  tactical  situation:  multiple  airfields  of 
varying  capabilities,  dozens  of  aircraft  taking  off,  landing  and 
transiting  within  the  controlled  airspace,  and  numerous 
deviations  to  flight  plans  resulting  from  combat. 

Next  was  the  issue  of  the  nature  of  the  algorithms  themselves. 

The  ATALARS  software  will  consist  of  a  mixture  of  table  look-ups 
or  data  base  functions,  decision  rules  or  Artificial  Intelligence 
(AI)  functions,  and  optimization  routines  to  establish  priorities 
among  incoming  aircraft  when  some  are  damaged,  low  on  fuel  or 
otherwise  incapable  of  following  their  original  flight  plans. 

The  algorithms  identified  and  discussed  in  this  study  are 
relatively  straightforward.  However,  the  architecture  envisioned 
for  the  system  will  support  the  more  sophisticated  functions  and 
algorithms  as  the  ATALARS  concept  matures. 

2.1.2  Roles  of  Pilots  and  Controllers.  In  order  to  develop  the 
algorithms  and  rules  which  must  be  employed  by  ATALARS,  the  roles 
of  the  pilot  and  ground  controller  in  the  present  ATC  environment 
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had  to  be  evaluated.  This  section  addresses  the  relationships 
that  must  exist  between  pilots  and  controllers,  the  basis  for 
those  relationships  and  the  control  information  required  by  each 
community . 

The  role  of  any  pilot  encompasses  three  actions  or 
responsibilities.  In  order  of  precedence  they  are: 

1.  Aviate  -  Operate  the  aircraft  in  such  a  manner  that 
will  attain  the  desired  mission  safely. 

2.  Navigate  -  Know  the  aircraft  position  and  altitude 
relative  to  a  known  reference  at  all  times. 

3.  Communicate  -  Advise  pertinent  authority  of  the 
aircraft  position,  altitude,  speed,  status  and  the 
pilot's  intentions,  as  required. 

Technology  now  provides  the  pilot  with  many  automa^d  functions 
to  determine  and  relay  aircraft  data,  thereby  freeing  him  to 
concentrate  on  his  number  one  priority  :  Fly  The  Aircraft.  Good 
examples  of  this  are  some  of  the  automatically  reported  data 
provided  by  JTIDS.  The  Precise  Participant  Location  & 
Identification  (PPLI)  message  tells  all  participants  in  the  JTIDS 
network  the  aircraft's  location,  speed,  altitude,  course,  and 
Selective  Identification  Feature/Identification  Friend  or  Foe 
(SIF/IFF)  codes,  as  well  as  a  wide  variety  of  other  information 
about  the  aircraft  and  its  activity.  The  Air  Platform  Status 
message  provides  a  similar  amount  of  information  about  the  status 
of  the  aircraft,  its  systems  and  its  weapons.  The  JTIDS  data 
link  is  intended  to  continue  functioning  under  wartime  conditions 
where  present  methods  of  air  traffic  control  data  automation  may 
be  degraded  or  compromised  and  would,  therefore,  be  unavailable 
to  the  pilot  and  to  the  ground  controller. 

Air  Traffic  Control  is  a  service  that  exists  to  promote  the  safe, 
orderly  and  expeditious  flow  of  air  traffic.  The  essence  of  ATC 
is  the  establishment  and  maintenance  of  appropriate  amounts  of 
separation  between  aircraft,  such  as  those  found  in  FAA  Order 
7110.65,  Air  Traffic  Control.  Safe  separation  is  maintained  by 
ATC  through  the  monitoring  of  flight  performance  and  the  issuing 
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of  advice/  direction  to  the  pilot.  ATC  must,  therefore,  under 
all  conditions,  have  aircraft  situational  parameters  immediately 
available  for  all  aircraft  within  its  controlled  airspace,  and 
have  means  of  communicating  advice  or  direction  necessary  for 
safety  of  flight  to  pilots  and  other  ATC  facilities.  Since 
military  aircraft  frequently  share  the  same  airspace  used  by 
civilian  aircraft,  ATALARS  must  be  compatible  with  the 
requirements  of  civil  aviation  as  well  as  military  aviation. 

From  the  viewpoint  of  civil  aviation  in  the  continental  United 
States,  airspace  is  generally  considered  to  be  either  controlled 
or  uncontrolled.  Controlled  airspace  starts  at  either  700  or 
1200  feet  altitude  depending  on  geographic  considerations  and 
continues  in  various  forms  to  60,000  feet  altitude.  All  flight 
is  uncontrolled  above  60,000  feet.  Civilian  flights  will  always 
be  considered  to  be  under  ATC  requirements.  Tactical  portions  of 
military  flights  are  generally  not  subject  to  ATC  requirements 
regardless  of  their  location  or  altitude.  Foreign  airspace  is 
categorized  in  a  similar  manner.  This  study  of  the  ATALARS 
concept  focuses  on  that  portion  of  flights  that  occurs  within 
controlled  airspace  during  the  non-tactical  portion  of  their 
missions.  Figure  4  is  a  diagram  of  U.S.  controlled  airspace, 
followed  by  definitions  of  the  various  airspace  categories  in 
Table  I. 

Controlled  airspace  is  divided  vertically  and  horizontally  by 
function  and  environment.  These  areas  are  delineated  in  the 
Federal  Aviation  Regulations  (FAR)  and  the  Airman's  Information 
Manual  (AIM).  They  are  further  functionally  detailed  by 
Instrument  Approach  Procedures  (IAP),  also  known  as  Approach 
Plates,  and  Enroute  Navigation  Charts  and  are  supported  by 
various  specific  mission  oriented  publications.  Two 
representative  Approach  Plates  are  shown  in  figure  5. 

Controlled  airspace  is  also  divided  by  aircraft  operations 
occurring  within  that  airspace.  Aircraft  are  either  in  the 
Enroute  or  Terminal  environment.  Each  environment  has  unique 
communications,  performance  and  procedural  requirements,  but 
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TABLE  I 

DEFINITION  OF  AIRSPACE  CATEGORIES 

AGL  Above  Ground  Level 

FL  Flight  Level  (feet  x 

100)  (used  to  define 
altitudes  >  18,000  ft.) 

MSL  Mean  Sea  Level 

S.M.  Statute  Miles 

Continental  Control  Area  The  Continental  Control  Area 

consists  of  airspace  above  14,500 
feet,  or  1,500  feet  above  surfaces 
higher  than  14,500  feet,  of  the  48 
contiguous  states  and  part  of 
Alaska . 

Control  Areas  Control  Areas  include  the  airspace 

associated  with  all  federal 
airways . 

Control  Zone  A  Control  Zone  extends  from  the 

surface  up  to  the  Continental 
Control  Area  and  includes  one  or 
more  airports.  The  control  zone 
is  normally  a  circular  area  within 
a  5  mile  radius  and  may  include 
extensions  necessary  for 
instrument  approaches  or 
departures . 
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TABLE  I 

DEFINITION  OF  AIRSPACE  CATEGORIES  -  (Cont'd) 

Terminal  Control  Area  (TCA)  A  Terminal  Control  Area  is 

controlled  airspace  which  requires 
all  aircraft  to  comply  with 
special  operating  rules  and 
equipment  requirements.  The 
airspace  extends  from  the  surface 
to  specified  altitudes  in  the  TCA. 

The  lateral  limits  of  the  TCA  are 
based  on  distance  from  the  primary 
airport,  and  may  have  greater 
lateral  limits  at  higher 
altitudes . 

Positive  Control  Area  Positive  Control  Area  is 

designated  in  the  48 
contiguous  states  and  parts  of 
Alaska  as  airspace  within 
which  all  aircraft  are 
subject  to  operating 
requirements . 

Transition  Areas  Transition  Areas  are  designed  to 

contain  IFR  operations  in 
controlled  airspace  transitioning 
the  terminal  and  en  route 
environments.  These  airspace 
designations  extend  from  700  feet, 
in  conjunction  with  an 
instrument  approach  or  1,200  feet  in 
conjunction  with  an  airway,  upward 
to  the  base  of  the  overlying 
controlled  airspace. 
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TABLE  I 

DEFINITION  OF  AIRSPACE  CATEGORIES  -  (Cont'd) 

Special  Use  Areas  In  addition  to  controlled  airspace 

there  are  several  special  use 
areas.  These  areas  are  Prohibited 
Areas  and  Restricted  Areas. 
Prohibited  Areas  are  defined  as 
areas  where  aircraft  flights  are 
prohibited.  Restricted  Areas  are 
not  wholly  prohibited  but  may  only 
be  entered  with  authorization  from 
the  controlling  agency.  Other 
special  use  areas,  such  as 
Military  Operations  Areas,  (MOAs), 
can  be  transited  without  an  ATC 
clearance  if  operating  under  VFR 
or  with  a  clearance  if  operating 
under  IFR . 
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Terminal  requirements  are  more  stringent  for  both  pilots  and 
controllers . 

2.1.3  Mission  Profile.  All  tactical  military  flights  are 
operated  under  specific  mission  directives  and  Instrument  Flight 
Rules  (IFR)  Flight  Plans.  The  flight  plan  provides  ATC  with 
advance  knowledge  of  flight  profiles  when  under  controlled 
conditions  and  provides  the  basis  for  in-flight  information 
transfer  requirements.  Missions  are,  however,  subject  to  change 
during  flight.  Such  changes  affecting  a  mission  in  progress  will 
be  dictated  by  the  pertinent  military  mission  commander  and 
passed  to  ATC  and  the  affected  aircraft  by  Command  and  Control 
tactical  communications  networks.  Changes  in  terminal  arrival 
requirements  may  be  dictated  by  airfield  conditions  and  will  be 
passed  by  ATC  to  the  aircraft  and  the  military  commanders. 

Within  Terminal  airspace,  ATC  becomes  the  governing  authority 
that  issues  directives  to  the  inbound  pilot  to  establish  the 
desired  sequence  and  spacing,  and  advises  him  of  local  weather, 
runway  and  safety  of  flight  conditions. 

With  the  mission  briefed  and  the  flight  plan  filed,  the  aircraft 
will  depart  the  origin  airfield  and  transit  to  the  tactical 
operating  area  within  controlled  airspace.  Aircraft  will  proceed 
to  the  directed  tactical  area,  via  the  assigned  route  and 
altitude  contained  in  the  flight  plan  to  arrive  at  a  specific 
geographical  point  at  a  prescribed  time.  Navigation  assistance 
may  be  provided  by  third  party  Tactical  Air  Control  Systems 
(TACS)  if  the  aircraft  is  unable  to  self  navigate  with  the 
required  degree  of  accuracy,  or  by  a  change  in  mission  direction 
after  take  off.  Today,  this  assistance  relies  heavily  on  active 
surveillance  and  voice  communications. 

Upon  changing  to  tactical  mode,  aircraft  will  generally  operate 
under  Emission  Control  (EMCON)  conditions  which  reduce  or 
eliminate  the  electromagnetic  radiation  from  the  aircraft  to 
reduce  the  probability  of  detection  by  enemy  forces. 
Electromagnetic  radiation  during  tactical  flight  will  be  limited 
to  safety  of  flight,  mission  completion  or  fire  control 
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requirements.  The  recommended  and  maximum  durations  in  the 
tactical  area  are  specified  in  the  mission  briefing. 

After  completing  the  tactical  portion  of  their  mission,  the 
aircrews  will  exit  the  tactical  area  via  the  routes  specified  in 
their  mission  briefs.  Tactical  entry/exit  points  will  vary 
randomly  to  deny  operational  pattern  detection  and  tactical  use 
of  that  information  by  enemy  forces.  This  allows  ATC  and  TACS  to 
acquire  and  track  returning  tactical  aircraft  without  the  need 
for  immediate  or  voluminous  communications.  The  tactical  exit 
point  may  not  be  the  same  for  all  aircraft.  Each  flight  or 
flight  unit  (leader  or  wingman)  may  have  a  separate  exit  point 
dependent  on  the  assigned  route  to  the  arrival  airfield  and  the 
aircraft  operational  characteristics.  This  also  serves  to  mask 
the  location  of  aircraft  landing  sites.  Each  mission  brief  will 
contain  route,  altitude  and  speed  information  for  each  aircraft 
or  flight  unit  from  the  tactical  exit  point  to  the  Initial 
Approach  Fix  ( IAF ) .  Strict  adherence  to  this  flight  profile  will 
assist  ATC  and  TACS  to  covertly  identify  returning  friendly 
aircraft.  Figure  6  depicts  the  major  features  of  a  tactical 
flight  profile. 

Battle  damage  or  otherwise  impaired  aircraft  may  deviate  from  the 
preferred  return  profile  in  accordance  with  a  specific  contingent 
profile  for  aircraft  returning  early,  late  or  in  need  of  priority 
routing.  Mission  commanders  may  vary  any  of  the  profile 
parameters  to  enhance  flight  safety  and  to  aid  in  ATC/TACS 
identification  of  returning  friendly  aircraft.  For  example, 
returning  aircraft  without  two  way  radio  communication  may  be 
assigned  an  altitude  different  from  the  primary  brief,  but  fly 
the  assigned  primary  route.  Other  combinations  of  altitude, 
heading  changes  or  time  of  arrival  over  specific  positions  may  be 
used  to  alert  ATC/TACS  to  changes  in  aircraft  status  prior  to 
energizing  aircraft  communications  or  data  transfer  systems. 

2.1.4  Operational  Decision  Considerations.  Normal  flight 
operations  can  be  viewed  as  well  defined  evolutions  during  which 
aircraft  perform  according  to  profiles  that  have  been  planned, 
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coordinated  and  briefed.  The  briefing  contains  all  the 
information  necessary  to  maneuver  the  aircraft  to  the  tactical 
operating  area,  conduct  the  tactical  mission  (including  primary 
and  secondary  mission  alternatives),  transit  to  the  landing  site 
(including  alternatives)  and  to  land  the  aircraft.  Within  this 
context,  aircraft  need  not  communicate  with  any  other  activity  at 
any  time,  from  starting  engines  to  shut  down,  so  long  as  the 
aircraft  performance,  weather  and  tactical  requirements  remain  as 
briefed . 

ACSI  focused  its  analysis  on  situations  requiring  significant 
deviations  from  briefed  operations  because  they  will  necessitate 
new  decisions  and  subsequent  communication .  These  situations 
will  arise  in  flight  and  will  require  either  a  permanent  or 
temporary  change  from  the  briefed  profile.  Typical  profile 
changes  may  be  dictated  by: 

a.  Failure  of  aircraft  mission  essential  equipment/battle 
damage 

b.  Runway  or  landing  field  status  degradation 

c.  ATC  equipment  failure 

d.  Weather  (making  field  or  route  unusable) 

e.  Tactical  mission  change 

f.  Potential  aircraft  hazard,  such  as  potential  collision 


Each  of  these  situations  requires: 

a.  Identification  of  profile  change  and  its  stimulus 

b.  Determination  of  the  immediacy  of  the  change 
requirement 

c.  Determination  of  all  options  for  change 

d.  Bounding  of  the  options  by  aircraft  capability  within 
the  time  allowed  (immediacy) 

e.  Interaction  analysis  to  determine  the  minimm  impact  to 
other  units  (air  and  ground) 

f.  Determination  and  display  of  resultant  choices 
prioritized  by  impact 
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g.  Selection  of  option  and  provision  of  direction  by  the 
controller 

2.1.5  ATALARS  Concept  of  Operation.  ATALARS  is  intended  to 
support  and  assist  the  ground  controller  in  performing  the  above 
functions.  Its  primary  use  will  be  in  a  multiple  terminal 
environment,  where  returning  aircraft  will  be  converging  on  their 
assigned  fields  and  will  be  encountering  departing  aircraft  and 
aircraft  that  are  transiting  the  area.  This  is  obviously  the 
area  of  heaviest  ATC  workload,  where  a  set  of  powerful  decision 
aids  will  have  the  most  benefit.  Much  of  the  ATALARS  logic  and 
many  of  its  algorithms  would  be  useful  in  tactical  aircraft 
control  systems  as  well,  and  should  be  considered  for 
incorporation  in  those  systems. 

Fundamental  to  the  operation  of  ATALARS  is  the  definition  of  a 
set  of  ATC  algorithms  which  will  be  developed  and  implemented  in 
the  software  of  the  ATALARS  Processor.  These  algorithms  will 
range  from  the  relatively  simple,  such  as  the  one  that  will  check 
to  see  if  an  aircraft  is  following  the  flight  plan  included  in 
its  mission  briefing,  to  the  sophisticated,  such  as  the  queuing 
routines  to  determine  who  lands  when  at  which  airfield.  Use  of 
these  algorithms  will  support  the  development  of  Artificial 
Intelligence  and  Expert  Systems  approaches  to  ATALARS. 

Artificial  Intelligence  or  Expert  Systems  use  predefined  rules  to 
search  fixed  condition  and  data  statement  tables  for  a  match  to 
key  words  in  specific  queries.  The  advantage  of  AI  is  that  it 
allows  a  natural  language  interface,  which  permits  the  operator 
to  input  questions  in  English  language  syntax.  For  the  non¬ 
technical  user,  this  may  be  easier  than  using  the  more  common 
relational  Data  Base  Management  Systems  (DBMS).  The  internal 
operation,  however,  is  similar  in  theory,  and  the  distinction 
becomes  blurred  if  the  DBMS  has  a  well  designed  user  interface. 

The  use  of  AI  architecture  would  allow  the  maximum  flexibility 
and  growth  potential.  Rules  governing  which  tabular  fixed  data 
to  access,  and  under  what  conditions,  would  be  applied  to  assist 
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the  ATALARS  controller  under  high  tempo  conditions  and  to  assure 
the  highest  probability  of  sound  decision  option  development. 

This  would  result  in  an  architecture  of  related  databases 
controlled  by  AI  rule  based  modules  and  reduce  the  work  intensity 
and  stress  of  the  ATALARS  controller. 

The  fixed  data  tables  are  assigned  one  to  each  data  category, 
such  as  specific  aircraft  performance  characteristics.  Taken 
from  the  aircraft  flight  manuals,  this  data  must  be  quite 
detailed.  For  an  aircraft  it  must  include,  but  not  necessarily 
be  limited  to  items  such  as: 


o  Type 

o  Number  of  crew 

o  Maximum  gross  weight 

o  Maximum  landing  weight 

o  Fuel  capacity  in  pounds 

o  Fuel  burn  rate  at: 

Full  speed  (Vmo) 

Cruise  speed 

Maneuver  speed  (maximum  lift/drag) 

Holding  speed  (maximum  endurance) 
o  Aircraft  speeds  at: 

Full  speed 

Cruise 

Maneuver 

Holding  (Approximately  1.5  Vso) 

Approach  (1.3  Vso) 

(Vso  =  stall  speed  in  landing  configuration) 
o  Jettison  stores  type 

o  Jettison  stores  weight 

ACSI  was  able  to  develop  a  functional  architecture  for  the  GCU 
which  will  meet  the  ATALARS  requirements.  There  will  be  four 
major  functions  that  must  be  accomplished: 


o  Man-machine  interface 

o  Message  generation 

o  Data  management 

o  Algorithm  processing 

The  man-machine  interface  is  the  controller's  workstation.  It 
will  consist  of  a  graphic  display,  a  text  display,  a  keyboard  and 
an  interactive  control  device  to  control  cursor  movement.  Input 
features  may  include  voice  processing.  The  displays  will  be 
capable  of  showing  the  status  of  all  elements  in  the  controlled 
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airspace.  This  is  where  all  controller  interactions  with  ATALARS 
will  take  place,  including  such  items  as  providing  alerts, 
display  and  selection  of  choices  for  action  and  system 
startup/shutdown.  Filters  will  enable  the  controller  to  manage 
his  workload  by  inhibiting  the  display  of  irrelevant  information. 
The  controller  will  be  capable  of  directly  accessing  any  of  the 
three  other  functions. 

The  message  generation  function  will  generate  the  JTIDS  messages 
needed  to  control  the  assigned  aircraft.  Conversely,  message 
generation  will  convert  received  messages  into  data  that  can  be 
easily  understood  by  the  controller,  handled  by  algorithm 
processing,  and  stored  in  the  data  base.  This  function  will 
provide  the  system's  interface  to  its  JTIDS  Class  2  terminal. 

ATALARS  will  require  the  storage  and  management  of  large  amounts 
of  data.  These  requirements  will  be  best  handled  by  establishing 
a  separate  data  management  function.  This  function  will  handle 
data  that  is  static,  such  as  aircraft  characteristics  and 
approach  plate  data;  and  data  that  is  dynamic,  or  constantly 
updated,  such  as  aircraft  position  and  status.  It  will  use  mass 
storage  devices  as  well  as  large  amounts  of  on-line  memory. 

Finally,  there  is  the  algorithm  processing  function.  This  is  the 
core  of  the  system  and  is  referred  to  as  the  ATALARS  Processor 
elsewhere  in  this  report.  Once  activated  by  the  controller,  the 
ATALARS  Processor  will  cycle  through  its  algorithms  in  a  defined 
sequence,  moving  information  to  and  from  the  other  three 
functions  as  required. 

Once  these  functions  have  been  modeled  and  tested  in  Phase  II, 
ACSI  will  be  able  to  make  a  preliminary  estimate  of  processing 
and  memory  requirements  for  the  ATALARS  GCU  hardware  suite.  In 
turn,  this  information  could  be  used  to  prepare  a  hardware 
architecture  for  the  GCU.  A  diagram  of  the  proposed  GCU 
functions  is  shown  in  figure  7. 

As  a  decision  aid  to  the  ground  controller,  this  system  may  be 
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expanded  and  refined  to  handle  a  wide  variety  of  aircraft  control 
situations  while  keeping  controller  workload  to  a  minimum. 

There  are  two  modes  of  operating  ATALARS  which  should  be 
considered,  and  the  software  should  be  designed  to  allow 
selection  of  one  mode  or  the  other.  In  the  "manual"  mode,  the 
ATALARS  processor  will  present  the  choices  available  to  the 
controller  to  respond  to  a  situation  in  descending  order  of 
priority.  When  the  controller  selects  one,  the  appropriate  JTIDS 
message(s)  will  be  constructed  and  sent.  Hence,  in  a  collision 
avoidance  situation,  the  controller  would  be  shown  various 
options  to  change  the  flight  parameters  of  one  or  more  of  the 
involved  aircraft.  When  one  of  the  options  is  selected,  JTIDS 
messages  would  be  automatically  composed  and  sent  to  the  affected 
aircraft . 

In  the  "automatic"  mode,  for  selected  types  of  situations  or 
sequences  of  activities,  the  ATALARS  Processor  would  select  the 
highest  priority  alternative,  then  prepare  and  transmit  the 
appropriate  message(s)  subject  only  to  controller  override. 
Although  this  mode  would  reduce  the  controller's  workload,  it 
should  be  used  with  caution,  since  it  runs  the  risk  of  having  the 
controller  lose  his  level  of  involvement  with  the  overall 
picture.  It  would  also  make  the  pilots  totally  dependent  on  the 
validity  of  the  software. 

The  system  could  also  be  set  up  to  provide  a  fail-safe  feature 
when  operating  in  the  manual  mode.  When  activated,  this  feature 
would  watch  for  controller  responses  to  certain  critical  alerts, 
such  as  a  potential  collision.  If  the  controller  fails  to 
respond  within  a  specified  time,  the  system  will  switch  itself  to 
the  automatic  mode,  select  the  highest  priority  option  and  send 
the  appropriate  message(s). 

The  selection  of  ATC  algorithms  for  the  proof  of  concept 
demonstration  was  a  result  of  analysis  of  the  flight  profiles 
created  for  the  scenario.  The  algorithms  are  listed  in  Table  II 
with  short  descriptions  of  each  one.  In  addition,  two  of  them, 
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TITLE 

Course 

Following 


Safe 

Separation 


Collision 

Avoidance 


Approach 

Plate 


TABLE  II 

ATALARS  ALGORITHMS 
FOR 

PROOF  OF  CONCEPT  DEMONSTRATION 


FUNCTION 

Checks  to  see  if  o 

aircraft  is  on  assigned 
course  and  speed,  warns  o 

pilot  &  controller  if 
off  course,  recommends 
recovery. 


Check  for  inadequate  o 

separation  between  aircraft. 
Warns  pilots  and  controller, 
recommends  maneuvers.  o 

o 

Checks  for  potential  o 

collisions,  warns  pilots 
and  controller,  recommends 
evasive  maneuvers.  Uses  o 

Safe  Separation  algorithm. 


o 

o 

o 

Gives  pilot  instructions  o 

for  approach  &  landing 

o 

o 


DATA  REQUIRED 

Current  position  heading 
speed  and  altitude 
Flight  plan,  including 
all  updates 


Current  position,  heading, 
speed  and  altitude  for  each 
aircraft . 

Minimum  separation  distance 
Type  of  aircraft 

Current  position,  heading, 
speed  and  altitude  for 
each  aircraft 

Position,  heading,  speed  & 
altitude  for  all  other 
controlled  aircraft 
Terrain  and  obstructions 
Map  &  other  boundaries  (FEBA, 
Minimum  Risk,  Missile 
Engagement  Zones,  etc.) 
Aircraft  performance 
characteristics 

Position,  heading,  speed  & 
altitude . 

Flight  plan,  updated 
Approach  Plate  data 
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TITLE 

Diversion/ 

Missed 

Approach 


Low  Fuel 


TABLE  II 

ATALARS  ALGORITHMS 
FOR 

PROOF  OF  CONCEPT  DEMONSTRATION  -  (Cont'd) 


FUNCTION 

Gives  controller  and  pilot 
instructions  for  alternate 
approach  and  landing  when 
originally  assigned  field 
will  not/can  not  be  used 


Calculates  range  available. 
If  insufficient  to  return 
to  assigned  field,  alerts 
pilot  &  controller. 
Recommends  action  to 
controller.  Uses 
Diversion/Missed  Approach 
algorithm  to  select 
alternate  fields. 


DATA  REQUIRED 

o  Position,  heading, 
speed  &  altitude, 
o  Approach  Plate  data 
for  original  field, 
o  Flight  plan  (alternate 
field  assignments) 
o  Airfield  data  for  all 
other  fields  in  control 
area  (location,  status, 
service  capabilities, 
approach  plates, 
landing/takeof f  queue) 
o  Aircraft  status  (fuel 
remaining ) 

o  Airfield  status  for 
original  field 
o  Aircraft  status  (fuel, 
stores,  systems,  etc.) 
o  Aircraft  performance 
characteristics 
o  Aircraft  position, 

heading,  speed  &  altitude 
o  Flight  plan 

(primary  &  alternate 
fields . ) 
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Collision  Avoidance  and  Low  Fuel,  are  discussed  in  more  detail  to 
show  more  of  the  considerations  that  will  have  to  be  addressed  as 
the  algorithms  are  more  fully  developed. 

2.1.6  Collision  Avoidance  Algorithms.  Collision  avoidance  is  an 
area  of  concern  that  can  be  managed  with  greater  simplicity  and 
speed  through  ATALAKS.  Using  the  constant  updates  to  aircraft 
positions,  altitudes,  speeds  and  headings  provided  to  the  ATALARS 
Processor,  conditions  could  be  defined  which  would  indicate  a 
potential  collision  hazard.  If  those  conditions  are  met,  an 
alert  would  be  provided  to  both  the  controller  and  the  aircraft. 

In  a  general  sense,  aircraft  headings,  speeds , altitudes  and 
separation  distances  become  the  data  elements  on  which  the  collision 
avoidance  algorithms  will  operate.  The  ATALARS  processor  would 
constantly  project  aircraft  courses  at  reported  speeds.  The 
resultant  estimated  positions  would  be  compared  first  to  those  of 
all  other  aircraft  in  the  controlled  airspace  and  then  to  the 
predefined  minimum  closure  or  separation  rules  set  as  the  thresholds 
for  controller  alert.  Upon  attainment  of  any  hazard  threshold,  the 
controller  would  be  alerted  by  a  high  intensity  blinking  message  on 
the  text  display  screen  such  as: 

"ALERT  -  TRACK  NO.  XXXX,  TRACK  NO.  YYYY  COLLISION  COURSE" 

This  would  be  accompanied  by  displaying  similarly  highlighted  and 
blinking  markers  on  the  elements  involved  on  the  display  screen.  A 
similar  alert  would  also  be  transmitted  to  the  aircraft  involved  for 
display  to  the  pilots. 

The  ATALARS  processor  would  then  create  a  prioritized  list  of  action 
options  available  for  controller/pilot  action.  These  options  would 
be  calculated  to  avoid  a  second  interference  threshold  with  a  third 
aircraft  and  to  change  the  aircraft  operating  parameters  to  the 
minimum  required  to  alleviate  the  situation.  This  will  serve  to 
simplify  the  controllers'  decisions  under  conditions  of  stress,  when 
quick  response  is  required  for  the  manual  mode  described  earlier. 

The  highest  priority  option  would  feed  directly  to  the  message 
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generation  module  in  the  automatic  mode. 

The  following  is  an  example  of  how  the  collision  avoidance 
algorithms  would  function  in  the  manual  mode:  Two  aircraft  are 
operating  in  airspace  where  the  separation  thresholds  have  been 
set  at  two  miles  horizontal  clearance  and  1,000  feet  vertical 
clearance.  They  are  on  converging  courses  that  will  cause  them 
to  collide  in  three  minutes  at  a  point  15  miles  from  their 
present  position.  Other  flights  are  at  the  same  altitude  to  the 
left  of  both  aircraft  flying  roughly  parallel  courses  5  to  7 
miles  away.  The  ATALARS  processor  would  give  the  alerts 
described  above,  then  calculate  the  directions  available  for 
heading  change.  Since  turning  left  would  cause  another  conflict, 
that  option  would  be  discarded.  The  amount  of  heading  change 
required  to  maintain  a  separation  of  at  least  two  miles  would  be 
calculated  for  each  aircraft.  The  aircraft  requiring  the  least 
heading  change  would  then  be  designated  as  the  priority  for 
change.  Since  no  other  aircraft  are  above  or  below  the  subject 
aircraft,  climb  and  descent  are  both  available  options. 

Climbing,  however,  takes  more  fuel  and  may  require  further 
adjustments  to  the  flight  profile  to  attain  the  mission  objective 
at  the  prescribed  times.  Therefore,  descent  is  the  preferred 
alternative . 

The  ATALARS  processor  would  project  the  alternative  flight 
profiles  and  compare  them  to  the  existing  profiles  of  all  other 
controlled  aircraft  for  maintenance  of  the  stipulated  separation 
rules.  This  would  provide  a  sifting  effect  as  the  system  derived 
a  set  of  alleviating  alternatives,  which  may  require  the  change 
of  more  than  one  flight  profile  to  avert  a  collision. 


The  options  presented  to  the  ATALARS  controller  would  then  appear 
as : 


1. 
2. 
3. 
n . 


TRACK  #  XXXX  CHANGE  HEADING  TO  AAA  DEGREES 
TRACK  «  YYYY  DESCEND  TO  BB, BBB  FEET 

other  options . 

TRACK  #  _ , _ 
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By  selecting  any  of  the  options  except  the  last  one,  the  controller 
would  cause  a  message  to  be  sent  to  the  designated  track  number(s) 
to  carry  out  the  change  described.  The  last  option  would  give  the 
controller  the  opportunity  to  insert  any  other  command  that  he 
chooses,  if  he  disagrees  with  all  of  the  other  options  presented. 
Once  the  command  is  inserted,  the  appropriate  message(s)  will  be 
sent  automatically. 

2.1.7  Low  Fuel  Algorithms.  An  example  of  this  evolution  would 
be  for  an  aircraft  to  exit  the  tactical  area  with  less  fuel  than 
was  planned.  Low  fuel  status  could  occur  from  battle  damage 
(implying  other  potential  flight  profile  change  requirements)  or 
from  unforeseen  high  thrust  maneuvers  during  the  tactical  phase 
of  the  mission  such  as  more  weapons  delivery  passes  than  planned, 
evasion  or  air  to  air  combat. 

Flights  are  normally  briefed  with  both  a  primary  and  secondary  or 
emergency  recovery  field.  In  today's  environment,  the  response 
to  most  low  fuel  situations  would  be  for  the  aircraft  to  divert 
to  the  emergency  destination  without  action  from  ATC  or 
communications  between  ATC  and  the  affected  aircraft. 

With  ATALARS  (JTIDS)  equipped  aircraft,  fuel  remaining  status  is 
regularly  reported  to  the  Ground  Control  Unit  without  pilot 
initiation.  The  ATALARS  processor  would  derive  the  fuel 
consumption  rate  with  each  update  and  check  to  see  that 
sufficient  fuel  remains  to  return  to  base.  The  ATALARS  processor 
would  also  compare  the  fuel  remaining  for  each  controlled 
aircraft  to  the  low  fuel  threshold  given  in  the  mission  briefing, 
and  would  alert  the  ground  controller  when  the  fuel  remaining  on 
any  aircraft  reached  that  level.  When  the  ATALARS  controller 
acknowledged  the  alert,  the  ATALARS  processor  would  go  through  a 
routine  where  it  would  access  the  primary  and  secondary  recovery 
fields  from  the  mission  briefing,  calculate  the  range  available 
on  the  remaining  fuel  at  various  speeds  and  altitudes,  determine 
whether  the  aircraft  can  reach  eithei  of  those  fields,  then 
determine  if  there  are  any  other  landing  sites  capable  of 
handling  the  aircraft  within  its  range.  The  ATALARS  processor 
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will  then  display  the  choices  available  to  the  controller  in 
descending  order  of  preference. 

In  response  to  the  change  stimulus  of  Low  Fuel  Remaining,  the 
choices  would  include  change(s)  to: 

o  Altitude 

o  Airspeed 

o  Route 

o  Landing  Site 

o  External  Stores 

o  Any  combination  of  the  above  items 

o  Finally,  as  the  last  resort  in  extreme  situations: 

EJECT 

Each  potential  change  would  be  compared  to  the  profiles  of  other 
controlled  aircraft  to  determine  potential  conflicts.  If 
conflicts  with  other  flights  result  from  the  selected  action, 
this  action  would  then  become  a  change  stimulus  to  the  flight 
profiles  of  the  affected  flights. 

Viable  changes  to  the  low  fuel  state  aircraft  would  thus  be 
determined  by  the  ATALARS  processor  and  displayed  to  the 
controller  based  on  the  capability  of  the  aircraft,  the 
situational  immediacy,  and  the  impact  on  other  aircraft  or  ground 
stations.  When  the  controller  selects  one  of  the  choices,  the 
ATALARS  processor  will  access  the  relevant  data  files,  such  as 
Approach  Plates  and  JTIDS  message  sets,  and  construct  and 
transmit  the  appropriate  messages. 

This  decision  process  makes  use  of  both  table  oriented  data  such  as 
the  mission  briefing/flight  plan,  aircraft  fuel  rates  at  various 
speeds,  altitudes  and  weights,  and  Approach  Plate  data,  as  well  as 
calculated  data  such  as  the  range  available  based  on  the  fuel 
remaining  at  various  consumption  rates.  The  table  oriented,  or 
fixed,  data  would  be  entered  into  tables  for  access  and  extraction 
by  the  computational  modules  which  develop  the  calculated  data. 

Fixed  data  could  be  entered  either  off  line  by  the  controller,  such 
as  Approach  Plate  information,  or  taken  automatically  from  data  link 
messages,  such  as  fuel  remaining.  The  calculated  data  can  then  be 
stored  in  predefined  storage  tables  for  prioritization  sorting, 
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decision  rule  application  and  display. 

Fuel  consumption  rates  vary  with  power  setting,  altitude  and 
aircraft  weight.  Fuel  consumption  increases  in  proportion  to 
aircraft  weight  at  a  given  speed  and  in  inverse  proportion  to 
altitude.  Consumption  can  be  calculated  when  given  values  of  the 
speed,  weight  and  altitude  variables.  Since  fuel  consumption  is 
less  sensitive  to  altitude  and  weight  than  it  is  to  speed,  altitude 
and  weight  can  be  normalized  into  gross  categories  requiring  only 
the  input  of  speed  to  derive  an  approximate  consumption  value.  For 
example,  altitude  can  be  split  into  two  categories:  above  10,000 
feet  and  below  10,000  feet.  Similarly,  weight  can  be  categorized 
for  each  aircraft  type  at  values  based  on  aircraft  empty  weight  plus 
two  fuel  values  and  two  external  stores  values.  These  values  could 
be  entered  into  a  simplified  conditional  formula  with  present 
aircraft  speed  to  arrive  at  remaining  aircraft  flight  range. 
Conversely,  the  maximum  allowable  speed  to  achieve  a  given  range  can 
be  derived  by  providing  the  desired  range  and  the  appropriate  weight 
and  altitude  values.  Since  the  ATALARS  processor  will  be  obtaining 
fuel  remaining,  altitude  and  speed  information  regularly  from  the 
ATALARS  equipped  aircraft,  these  values  could  be  used  to 
automatically  update  the  current  operating  data  table  from  which  the 
processor  would  calculate  range/  endurance. 

Aircraft  are  assigned  track  identification  numbers  which  are  unique 
to  each  aircraft  in  the  network.  This  track  number  is  the  reference 
for  specific  aircraft  communications  or  operating  data.  The  ATALARS 
controller  can  either  "hook"  the  aircraft  with  an  interactive 
control  device,  such  as  a  mouse  or  joy  stick,  or  he  may  include  the 
track  number  as  reference  in  keyboard  query  commands.  The  AI 
interface  system  would  support  queries  such  as,  "What  is  endurance?" 
or,  "What  is  range?"  for  a  "hooked"  aircraft.  If  keyboard  entry  is 
preferred,  the  controller  would  enter  commands  such  as,  "For  (track 
#),  what  is  endurance?"  or,  "For  (track  #),  what  is  range?". 
Geographic  data  resident  in  the  ATALARS  data  base  could  also  be 
accessed  to  allow  automatic  determination  of  landing  fields  within 
the  range  of  a  specified  aircraft.  At  present,  these  considerations 
are  addressed  by  individual  pilots  and  controllers  and  therefore  add 
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to  their  workload.  Consequently,  the  results  will  vary  with 
individual  capabilities  and  the  amount  of  time  available  to  apply  to 
the  problem. 

2.1.8  Data  Requirements.  Much  of  ACSI's  analysis  focused  on  the 
exchange  of  data  between  pilot  and  controller.  The  data  elements 
were  then  compared  to  the  requirements  for  ATC  in  the  ATALARS 
environment.  The  analysis  covered  all  aspects  of  a  typical 
flight,  starting  with  the  pre  flight  briefing  then  proceeding 
through  the  takeoff,  enroute,  approach  and  landing  segments  as 
well  as  some  common  contingencies. 

As  can  be  seen  from  the  frequent  references  to  it,  the  Mission 
Briefing  contains  much  information  that  will  be  essential  to 
efficient  operation  of  ATALARS.  Air  Force  Regulation  60-16, 

"General  Flight  Rules,"  sets  the  broad  requirements  for  Preflight 
Planning  (Sect.  2-1)  and  Briefings  and  Prohibitions  (Sect.  2-6). 
Major  commands  add  their  own  supplements  which  are  further 
amplified  by  pilots  in  command  or  formation  leaders.  The 
contents  of  a  typical  briefing  for  a  Close  Air  Support  (CAS) 
mission  are  shown  in  figure  8.  Weather,  ceilings,  visibility, 
altimeter,  departure  instructions  (such  as  heading,  fix,  climb, 
intermediate  and  final  altitude)  and  enroute  transition  may  be 
briefed  minutes  before  departure.  This  data  would  then  passed  to 
the  Ground  Control  Unit  via  command  and  control  networks  so  that 
the  controller  is  then  prepared  to  monitor  outbound  flights  and 
provide  direct  or  redirect  advisories  if  required. 

Takeoff  in  the  terminal  environment  may  be  conducted  without 
aircraft/  ATC  communication.  Actual  takeoff  clearance  can  be 
issued  by  a  local  controller  with  light  signals  from  the 
departure  end  of  the  active  runway,  assuring  the  departing  pilot 
that  all  other  aircraft  are  clear  of  his  intended  takeoff  and 
departure  path.  Transition  to  the  Enroute  environment  occurs  at 
the  departure  fix,  which  normally  includes  an  exchange  of  the 
data  shown  in  Table  III. 

The  enroute  flight  environment  requires  the  least  amount  of  flight 
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FIGURE  8.  GENERAL  MISSION  BRIEFING 


Initial  Operation  Brief  (CAS): 

General  target  information 
Number  of  squadrons  participating 
Flight  makeup: 

Mission  leader 
Order  of  flights 

Specific  positions  (Element  leads,  wingmen,  etc.) 

Weather  Briefing: 

Home  base  current  weather 

Enroute 

Over  target 

At  tanker 

On  return 

Intelligence  Briefing: 

Overall  intell  assessment  of  situation  in  battle  area 
Stateside  observations 
Specific  target  information 

Target  make  up  (number,  type,  etc.) 

Type  of  construction 
Precise  location 
Vulnerability 
Defenses : 

Enroute 
At  target 

Forward  edge  of  battle  area  (FEBA) 

Forward  line  of  own  troops  (FLOT) 

Safe  areas: 

Actions  to  take 
Safest  part  of  area 
Points  of  contact 
Who/how  to  contact 
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FIGURE  8.  GENERAL  MISSION  BRIEFING  -  (Cont'd) 
Day/night  actions 

Use  of  pointee/talkees ,  chits,  gold  pieces 
Personal  Equipment  Briefing: 

Ejection  sequence/procedures 
Maneuvering  chute 
Locator  beacon 
Use  of  survival  radio 
Issue  guns/ammo 

Use  of  various  other  survival  items 

Weapons/Ordnance  Briefing: 

Type  of  ordnance  loaded 
Destruction  capacity 
Minimum  altitude  for  release 
Specifics  on  load 
Arming/dearming  procedures 
Cautionary  items 

Operations  Briefing  -(Specific) 

Start  engine  time/UHF  frequency 
Marshalling  "  /  "  " 

Ordnance  check/procedures 
Take  off  time/sequence/frequency 
Tanker  location  ( anchor ) /procedures/frequencies 
Time  on 
Fuel  offload 
Time  off 
Route  &  target: 

Outbound  control/frequencies 

IFF/SIF  Mode  &  Code 

Ingress  to  target/heading/altitude 

Controller  in  target  area/frequencies 

Time  on  target 

Tactics/weather  dependent 

Maximum  stay  time  on  target 


( ATALABS . TX/317C  ] 


-34- 


ATALAKS  PH  AS  K  1  KKPOKT 
HABCB  1988 


FIGURE  8.  GENERAL  MISSION  BRIEFING 

Egress  from  area/heading/altitude 
IFF/SIF  Mode  &  Code 
Uf  e  of  minimum  risk  corridor 
Altitude/Code  outside  MRC 
Recovery  procedures: 

Controller /frequency 
Type  of  Approach 
Diversion : 

Primary  alternate 
Secondary  " 

Hung  ordnace  procedures 
Communications  out  procedures 
Switchology 
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TABLE  III.  ENROUTE  DATA  ELEMENTS 

AIRCRAFT  GROUND 


SEND 

REOUEST 

SEND 

ID 

WEATHER 

ACKNOWLEDGMENT 

POSITION 

ALTIMETER 

COURSE 

ALTITUDE 

CHANGE  TO: 

ALTITUDE 

TRUE  AIR  SPEED 

ROUTE 

TRUE  AIR  SPEED 

ACKNOWLEDGMENT 

ALTITUDE 

ALTIMETER 

STATUS 

MIN  RISK  CORRIDOR 

FUEL 

MISSILE  ENGAGEMENT 

ZONE 

WEAPONS 

FEBA 

SYSTEMS 

WEATHER 

DAMAGE 

REQUEST 

FUEL 

STATUS 
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or  advisory  data  to  be  transferred  between  the  pilot  and  the  ground 
controller.  The  data  generated  or  requested  by  both  the  aircraft 
and  the  controller  is  the  same  as  that  initially  exchanged  upon 
transition  to  the  enroute  environment. 

The  terminal  environment  requires  much  more  information  to  be 
exchanged.  For  normal  operations  with  fully  capable  aircraft  and 
crew,  this  can  be  handled  by  a  standard  set  of  data  which  may 
also  be  transferred  by  standard  message  format.  In  addition,  the 
data  exchange  rate  will  increase  with  increasing  proximity  to  the 
runway.  Landing  and  takeoff  both  occur  in  the  Terminal 
environment  and  include  operations  from  the  runway  to  a 
transition  fix  at  a  designated  altitude.  Table  IV  depicts  the 
data  elements  generated  or  requested  by  both  the  aircraft  and  ATC 
in  the  Terminal  Approach  and  Landing  environment. 

Mission  briefing  material  will  include  mission  abort  instructions 
which  contain  the  same  types  of  data  as  the  approach  information 
requirements.  The  abort  or  divert  approach  data  is  provided  for 
those  cases  where  there  is  aircraft  status  reduction  in  power 
plant,  navigation  or  weapons  systems  and  it  cannot  reach  its 
assigned  recovery  field. 

Pilots  may,  at  any  time,  request  updates  to  any  information 
normally  provided  by  the  ATC  system. 

2.2  Data  Set  Communication  Requirements 

2.2.1  JTIDS  Description.  In  all  of  the  efforts  to  refine  the 
ATALARS  concept  and  plan  for  an  early  proof  of  concept 
demonstration  in  Phase  II,  it  has  been  assumed  that  the  ATALARS 
automatic  data  link  is  to  be  implemented  using  the  Joint  Tactical 
Information  Distribution  System  (JTIDS). 

JTIDS  is  a  Time  Division  Multiple  Access  (TDMA)  communications 
system  operating  in  the  L-Band  frequency  range.  It  provides  jam 
resistant  digital  communication  of  data  and  voice  for  command  and 
control,  navigation,  relative  positioning  and  identification.  Its 
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TABLE  IV.  APPROACH  &  LANDING  DATA  ELEMENTS 


AIRCRAFT 


GROUND 


SEND 


REQUEST 


SEND  REQUEST 


ACKNOWLEDGMENT 

FUEL 

STATUS 


ALTERNATE  ROUTE  IAP : 

WEATHER  UPDATE  POSITION 

ALTITUDE 
TIME 

TYPE  LANDING 
TDZ  POSITION 
RUNWAY  HEADING 
HOLDING  INSTRUCTIONS: 
POSITION 
DIRECTION 
LEG  LENGTH 
STD/NON-STD 
EAC  TIME 
IAF  : 

POSIT 
ALTITUDE 
COURSE 
GLIDE  SLOPE 
FAF: 

POSITION 

ALTITUDE 

DH 

TDZ  ELEVATION 
CEILING 
VISIBILITY 
WIND 

ALTIMETER 
MISSED  APPROACH: 
COURSE 
ALTITUDE 
WEATHER 


FUEL 

STATUS 

TYPE  LANDING 
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operating  range  is  greater  than  300  nautical  miles  (nominally)  in 
line-of-sight ,  with  an  extended  range  option  of  500  nautical  miles. 
JTIDS  communications  operate  on  the  principle  of  time  sharing  the 
same  randomly  hopping  frequencies  as  other  subscribers  within  the 
communications  net.  To  accomplish  this,  a  time  cycle  (or  epoch)  is 
established  in  which  time  slots  are  repeated  every  12.8  minutes. 

The  epoch  is  divided  into  98,384  individual  time  slots  of  7.8125 
milliseconds  each,  thus  providing  128  time  slots  per  second  for  the 
transmission  or  reception  of  data. 

Each  subscriber  is  assigned  specific  time  slots  for  transmission 
and  reception  based  on  the  particular  message  requirements 
necessary  to  support  its  mission.  A  subscriber  may  have  many 
transmit  time  slot  assignments,  consecutive  or  spaced,  within  the 
epoch.  Additionally,  a  subscriber  may  share  any  of  the  128  nets 
that  JTIDS  is  capable  of  supporting,  depending  on  how  the 
subscriber's  terminal  is  programmed.  Each  net  functions  in  the 
same  time  reference  and  line-of-sight  area  but  with  a  different 
frequency  scheme.  While  typically  only  one  subscriber  will  be 
designated  as  being  able  to  transmit  in  a  specified  time  slot, 
many  subscribers  may  be  designated  to  receive  on  a  specific  net 
in  a  specific  slot.  Thus  JTIDS  permits  subscribers  to  track  each 
other  and  permits  them  to  select  the  information  they  need  from 
the  interoperating  nets  to  "see"  what  the  other  subscribers  "see" 
in  both  the  surface  and  air  environments. 

Within  JTIDS,  one  subscriber  is  designated  to  serve  as  the  time 
reference,  synchronizing  all  the  other  subscribers  to  the  same 
timing  throughout  the  interoperating  nets.  With  each  subscriber 
accurately  synchronized  to  a  common  system  time,  and  with  a 
signal  structure  that  permits  accurate  signal  Time-Of-Arrival 
(TOA)  measurements,  JTIDS  can  also  provide  a  relative  navigation 
and  position  location  capability  with  other  JTIDS  subscribers. 

Also  included  within  the  JTIDS  concept  is  a  document  called  the 
Technical  Interface  Design  Plan  (TIDP).  The  TIDP  defines,  in 
detail,  the  set  of  messages  and  their  content  which  will  be  used 
in  the  exchange  of  digital  information  on  a  JTIDS  communication 
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net.  Since  the  JTIDS  TIDP  is  a  classified  document,  all 
references  to  JTIDS  messages  in  this  report  will  be  generic. 

2.2.2  Comparison  of  JTIDS  and  ATALARS  Requirements.  JTIDS  is 
recommended  as  the  ATALARS  data  link  for  several  reasons.  First, 
it  can  handle  and  effectively  present  the  data  and  messages 
needed  for  ATC.  Next,  through  its  relative  navigation  and  PPLI 
reporting  capabilities,  JTIDS  can  provide  the  desired  indirect 
surveillance  of  controlled  aircraft  to  the  ground  controller. 
JTIDS  also  provides  the  secure  transmission  and  jam  resistance 
needed  for  ATC  in  the  tactical  environment.  Finally,  JTIDS  is 
subject  to  the  standards  for  tactical  C3  interoperability,  so 
ATALARS  will  employ  systems  already  being  developed  for 
application  on  a  wide  variety  of  aircraft  and  ground 
installations.  JTIDS  will  allow  ATALARS  to  interface  with  the 
Air  Defense  Tactical  Systems. 

The  capabilities  of  JTIDS  were  compared  to  the  requirements  for 
the  ATALARS  proof  of  concept  demonstration,  first  to  determine 
the  feasibility  of  using  JTIDS  as  the  ATALARS  data  link  and 
second,  given  the  feasibility,  to  determine  the  scope  of  any 
necessary  changes.  Analysis  of  the  TIDP  revealed  that  all  the 
parameters  required  to  support  the  Approach  Control  aspects  of 
ATALARS  are  contained  within  the  JTIDS  message  sets.  The 
analysis  did  indicate,  however,  that  some  of  the  required 
information,  although  contained  in  the  TIDP,  was  fragmented  and 
was  not  conducive  to  efficient  operation  of  an  ATALARS  system. 

In  these  cases  several  messages  would  have  to  be  transmitted  to 
convey  the  required  information  where,  with  some  judicious 
modifications,  a  single  message  might  suffice.  At  first  it 
seemed  reasonable  to  redefine  portions  of  the  TIDP  or  specify  new 
messages  custom  tailored  to  support  the  efficient  operation  of 
the  ATALARS  concept.  After  careful  consideration,  however,  this 
idea  was  dropped  because  it  would  eliminate  completely  any 
possibility  of  demonstrating  the  ATALARS  concept  with  live 
elements  that  are  currently  JTIDS  capable.  By  not  modifying  the 
TIDP,  a  live  demonstration  of  the  ATALARS  concept  might  be 
possible  using  F-15's  which  have  been  equipped  with  a  JTIDS 
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capability.  Although  the  government  currently  has  no  plans  for 
such  a  live  demonstration,  one  could  be  accomplished  if  desired, 
which  would  not  be  the  case  if  the  TIDP  were  modified.  In 
addition,  several  messages  that  would  support  ATALARS  were  found 
in  the  predecessor  to  the  JTIDS  TIDP,  known  as  the  Interim  JTIDS 
Message  Set  (IJMS).  Some  of  these  messages  can  be  handled  by  the 
F-15's  JTIDS  terminal  and  some  cannot.  The  EJSE  will  be  able  to 
handle  most  of  the  messages  when  the  upgrades  now  in  process  for 
the  Modular  Control  Equipment  (MCE)  program  are  complete. 
Subsequent  analysis  indicated  that  the  inefficiencies  of  the  TIDP 
relative  to  ATALARS  can  be  tolerated,  provided  that  no  high 
capacity  scenarios  are  attempted. 

Although  there  are  no  current  plans  by  the  Air  Force  to  implement 
it,  the  JTIDS  TIDP  includes  a  message  that  can  assign  multiple  way 
points  which  could  be  used  for  approaches  or  for  flight  plans.  It 
also  includes  a  message  that  could  provide  close  control  up  to  a 
point  10  seconds  before  touchdown  and  also  includes  the  capability 
to  tie  into  the  aircraft's  auto  pilot  and  fly  the  aircraft  in  a 
manner  similar  to  flying  a  Remotely  Piloted  Vehicle.  Use  of 
messages  such  as  these  would  add  significantly  to  the  capabilities 
of  ATALARS. 

To  determine  which  messages  could  be  used  in  the  ATALARS 
application,  the  various  types  of  data  needed  in  the  different 
environments  were  analyzed  for  common  elements  and  those  common 
elements  were  compared  to  the  contents  of  the  messages.  The 
common  elements  of  data  are  shown  in  Table  V.  Descriptions  of 
IJMS/TADIL-J  messages  that  could  be  used  with  ATALARS  are  listed 
with  the  platforms  in  which  they  are  implemented  in  Table  VI. 

2.3  EJSE  Utilization  for  the  Proof  of  Concept  Demonstration 

2.3.1  EJSE  Description.  Analysis  during  this  study  has  shown 
that  JTIDS  provides  both  the  indirect  surveillance  and  the 
automatic  data  link  capabilities  required  by  ATALARS. 

Consequently,  the  Enhanced  JTIDS  System  Exerciser,  which 
was  developed  by  ACSI  to  support  the  verification  and 
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TABLE  V 

1 

ATALARS 

INFORMATION  EXCHANGE 

1 

PILOT  TO  CONTROL 

TADIL-J /I JMS 

CONTROL  TO  PILOT 

1 

MESSAGES 

■ 

1 

GROUND  PHASE 

■ 

Identification,  Position 

/*Air 

/ 

/ 

1 

/PPLI 

/ 

/ 

Request  for  taxi,  takeoff 

/C4-3 

/ 

/ 

1 

instructions 

/ 

/ 

/ 

■ 

/ 

/**V1-1 

/ 

Taxi  instructions 

■ 

/ 

/ 

/ 

RW  in  use,  etc. 

1 

Acknowledgments  (through 

/ 

/ 

/ 

operator  ack  selection 

/ 

/ 

/ 

Ceiling,  visibility, 

1 

in  cockpit) 

/ 

/1 1  -1 

/ 

altimeter  setting, 

/ 

/ 

/ 

wind,  (direction, 

| 

/ 

/ 

/ 

speed ) 

/ 

/ 

/ 

■ 

/ 

/**C1-11/ 

Clearance  to  taxi/ 

■ 

/ 

/ 

/ 

change  to  departure 

■ 

/ 

/ 

/ 

frequency 

1 

/ 

/ 

/ 

1 

ENROUTE  PHASE 

| 

/ 

/ 

/ 

ID,  position,  alt,  etc. 

/*Air 

/ 

/ 

■ 

/PPLI 

/**C1-11/ 

Changeover  instructions 

■ 

/ 

/ 

/ 

to  enroute  controller 

■ 

Operational  status 

/*Plat- 

/ 

/ 

1 

/  form 

/ 

/ 

/Status 

/ 

/ 

1 

Request  weather  update 

/**Data 

/ 

/ 

/Update 

/Il-ll 

/ 

Transmit  weather  update 

1 
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TABLE  V 

ATALARS 

INFORMATION  EXCHANGE  - 

TADIL-J/I JMS 
MESSAGES 

/Request  /I1-3  / 

/  /I1-4  / 

/  /H-5  / 

/  /  / 

/  /  / 

/  /  / 

/  /*Air  / 

/  /Track  / 

/  /  / 

/  /  / 

/  /*Miss-  / 

/  /  ion  / 

/  /Asgnmt  / 

/  /  / 

/  /*Vector/ 

/  /  / 

TARGET  AREA  PHASE 


/  /**Refer/ 
/*  Air  /ence  Pt/ 
/PPLI  /  / 
/♦Plat-  /  / 
/  form  /  / 
/  Status  /  / 
/  /**C1-11/ 
/  /  / 


CONTROL  TO  PILOT 

Transmit  upper  air 
data 

Transmit  severe  weather 
data 

Hostile  information 
from  ATALARS,  AWACS , 

CRC ,  etc. 

Repositioning  of 
Minimum  Risk  Corridor, 
FEBA,  etc. 

Change  of  altitude/head¬ 
ing/speed  for  traffic 
control 

Hazard  information 


Handover  to  target  area 
control 
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TABLE  V 


ATALARS 

INFORMATION  EXCHANGE  -  (Cont'd) 


PILOT  TO  CONTROL 

TADIL-J./I  JMS 

CONTROL  TO  PILOT 

MESSAGES 

RETURN  TO 

BASE  PHASE 

Request  for  WX  update 

/C4-3 

/ 

/ 

/ 

/Il-l 

/ 

Weather  observation, 

/ 

/thru 

/ 

severe  WX,  ceiling, 

/ 

/I1-5 

/ 

visibility,  altimeter 

/ 

/ 

/ 

etc . 

Request  for  airfield 

/C4-3 

/ 

/ 

status 

/ 

/Air¬ 

/ 

Critical  information 

/ 

field 

/ 

transmitted 

/ 

/Status 

/ 

Landing  information 

/ 

/**  VI- 

1/ 

Runway  in  use, 

/ 

/ 

/ 

altitude,  airspeed, 

/ 

/ 

/ 

heading,  etc. 

/ 

/ 

/ 

Operation  data 

/♦Plat- 

/ 

/ 

/  form 

/**  VI- 

1/ 

Missed  approach/diver¬ 

/  Status 

/ 

/ 

sion  information 

/ 

/ 

/ 

♦Messages  currently  processed  by  EJSE 
♦♦Messages  to  be  processed  in  MCE  upgrade  to  EJSE 

Other  messages  will  require  approval  and  expansion  for  applicability  to 
ATALARS . . 
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1  . 


2. 

3. 

4. 

5. 


6. 

7  . 

8. 

9. 

10 

11 


12. 

13. 


TABLE  VI. IJMS/TADIL-J  MESSAGES  FOR  ATALARS 


PLATFORM  (1) 


Air  PPLI 

(Precise  Participant  Location  & 
Identification ) 

Air  Platform  Status 

Air  Track 

Aircraft  Control  Message 

Aircraft  Vectoring  and  Close 
Control  Message 

Area  Severe  Weather  Report 

Airfield  Status 
Controlling  Unit  Change 
Flight  Path 

Handover 

Interrogation  Message 

(to  request  weather  info,  etc.) 

Land  (Ground)  Point 

Mission  Assignment 


MESSAGE  EJSE 
TYPE  (2) 

TADIL-J  X 


TADIL-J  X 

TADIL-J  X 

I JMS  X 

I JMS  X 


I  JMS 

TADIL-J 

TADIL-J  X 

TADIL-J 


TADIL-J  X 

I  JMS  X 

TADIL-J  X 

TADIL-J  X 


E-3  MCE  F-l 5 
XXX 

XXX 

XXX 

X 

X 


XXX 

X  X 

X 

XXX 

XXX 
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14.  Moving  Severe  Weather  Report 

15.  Pairing 

16.  Pairing  Association  MSG.  for 
Tracks  &  Special  Points 

17.  Precision  Aircraft  Direction 

18.  Target/Track  Correlation 

19.  Upper  Air  Data  Report 

20.  Vector 

21.  Weather  Observation 


PLATFORM 


MESSAGE  EJSE 

TYPE  121  Er3  MCE  F-15 


I JMS 


TADIL-J  XXX 


I JMS  X  X 


TADIL-J 

TADIL-J 

I  JMS 

TADIL-J  X  X  X  X 

I  JMS 


Note:  (1)  This  is  a  list  of  messages  of  use  to  ATALARS,  and  is  not 

necessarily  a  complete  listing  of  messages  processed  by 
the  EJSE,  E-3 ,  MCE  or  F-15. 

(2)  EJSE  Messages  include  those  being  implemented  for  the  MCE 
Program,  which  will  be  available  by  August,  1988. 
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demonstration  of  the  JTIDS  concept  is  the  logical  candidate  for 
the  proof  of  concept  demonstration.  The  EJSE  is  capable  of 
exercising,  monitoring  and  participating  in  a  JTIDS  TDMA  network. 

It  is  a  self-contained,  user  friendly  system  that  is  capable  of 
simulating  JTIDS  elements  while  collecting  and  displaying  all  the 
various  parameters  by  which  the  JTIDS  network  operations  are 
monitored . 

The  EJSE  consists  of  a  Terminal  Group  (TG),  a  Simulation  Group  (SG) 
and  a  Display  Group  (DG),  all  of  which  are  interconnected  via  a 
Local  Area  Network  (LAN).  The  system  is  diagrammed  in  figure  9. 

For  application  of  the  EJSE  for  the  ATALARS  proof  of  concept 
demonstration,  only  the  Simulation  Group  and  the  Display  Group  will 
be  used.  The  Terminal  Group  would  be  used  only  if  the  government 
elected  to  conduct  a  live  demonstration. 

Currently  the  Simulation  Group  provides  both  off-line  and  on-line 
functions  for  the  EJSE.  Off-line,  the  Simulation  Group  is  used  to 
create  event  driven  scenarios  from  user  supplied  event  data  which 
can  be  stored  on  tape  or  disk.  These  event  data  are  geographic 
locations  and/or  times  depending  on  the  requirements  of  the  scenario 
and  the  element  type  being  simulated.  An  element  type  is  either  a 
participating  unit  (JTIDS  equipped)  reporting  its  own  position  and 
status,  or  a  track  whose  location  is  being  reported  by  a 
participating  unit.  The  Simulation  Group  creates  a  data  base 
containing  element  report  message  data  and  positions  used  in 
extrapolation  of  simulated  tracks.  A  position  report  or  track 
message  is  then  created  for  each  element  at  the  recurrence  rate 
specified  by  the  user.  These  element  report  messages,  with 
extrapolated  position  data,  are  then  written  to  magnetic  storage 
media  with  any  additional  command  and  control  messages  interleaved 
at  their  appropriate  times.  The  result  is  a  time  ordered  scenario 
tape  or  disk  file  containing  all  the  JTIDS  messages  required  to 
simulate  the  desired  tactical  environment.  On-line,  the  Simulation 
Group  processes  messages  from  a  Scenario  file  for  transmission  to 
the  Terminal  Group  and  Display  Group  via  the  LAN. 

The  Display  Group  creates  a  tactical  situation  display  on  the  basis 
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of  element  reports  received  via  the  LAN.  This  situation  display 
depicts  the  type,  heading  and  speed  of  elements  reporting  or  being 
reported  on  the  JTIDS  network.  This  display  also  provides 
controller  selectable  options  for  displaying  both  simulated  and  real 
network  data  in  real  time,  and  can  provide  filtering  by  element  in 
either  environment.  These  elements  are  selected  for  display  based 
on  their  range  from  the  display  center  and  on  a  specified 
prioritized  element  type  filter  list.  Each  element's  position  on 
the  display  screen  is  scaled  relative  to  its  reported  position  and 
to  the  operator's  specification  of  display  center  and  range.  In 
addition,  an  operator  may  request  the  display  of  data  blocks  with 
optional  filtering  to  show  as  little  or  as  much  information  as 
desired  for  any  or  all  of  the  displayed  elements. 

2.3.2  EJSE  Modifications  Required.  To  support  an  ATALARS  proof 
of  concept  demonstration  in  Phase  II,  some  modifications  will  be 
made  to  the  EJSE  which  will  enhance  the  system's  current 
capabilities.  The  Display  Group  will  be  modified  so  as  to 
function  as  an  ATALARS  Ground  Control  Unit  rather  than  as  a 
network  monitor  and  the  Simulation  Group  will  be  modified  to 
provide  a  real-time  interactive  simulation  capability. 

Added  to  the  Display  Group's  current  capabilities  will  be  the 
capability  to  assess  the  current  situation  and,  on  the  basis  of 
that  assessment,  to  automatically  generate  and  transmit  JTIDS 
messages.  This  control  capability  will  be  provided  through  the 
implementation  of  the  ATALARS  algorithms  discussed  earlier  and 
developed  during  Phase  I  and  in  Phase  II,  The  Display  Group  will 
maintain  a  data  base  containing  the  key  information  (as  defined 
by  the  algorithms)  for  each  element  in  a  given  scenario.  This 
information  will  be  initialized  at  the  beginning  of  the  scenario 
and  will  be  updated  from  information  gleaned  from  the  JTIDS 
messages  transmitted  by  the  individual  elements  over  the  course 
of  the  scenario.  At  regular  intervals,  the  Display  Group  will 
execute  iteratively  through  the  ATALARS  algorithms  to  determine 
if  any  of  the  elements  must  be  vectored  to  a  new  heading,  speed, 
altitude  or  position.  For  those  elements  which  must  be  vectored 
as  described  above,  the  Display  Group  will  present  the  operator 
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with  the  action  required,  or  offer  recommended  choices,  if 
appropriate.  When  the  operator  affirms  the  action  required,  or 
selects  one  of  the  choices,  the  Display  Group  will  format  the 
appropriate  legitimate  JTIDS  message  and  transmit  it  over  the 
LAN. 

In  addition  to  determining,  formatting  and  transmitting  these 
position  related  JTIDS  messages,  the  Display  Group,  in  its  role  as 
Ground  Control  Unit  will  also  transmit  net  management  type  messages 
to  the  scenario  elements.  These  net  management  messages  will  allow 
participating  elements  to  report  their  position  and  status  at 
increasing  frequency  as  they  get  closer  to  landing.  When  fully 
developed,  it  is  anticipated  that  the  ATALARS  Ground  Control  Unit 
will  be  assigned  its  own  JTIDS  net,  due  to  the  large  number  of  slots 
it  will  require.  The  Ground  Control  Unit  will  then  distribute  its 
time  slots  to  elements  under  its  control  based  upon  the  current 
situation,  both  overall  and  specific  to  the  element  receiving  the 
slots . 

In  order  for  the  Simulation  Group  to  support  an  ATALARS 
demonstration,  its  simulation  capability  must  be  made  to  run  in 
real-time  and  be  interactive  with  command  messages  received  from 
the  Display  Group  over  the  LAN.  Converting  the  Simulation 
Group's  scenario  generation  capability  to  run  in  real  time  will 
require  some  restructuring  of  the  program,  but  not  a  significant 
restructuring,  because  most  of  the  program  is  already  set  up  for 
real-time  operations.  What  is  necessary  is  to  have  the  system 
create  its  element  data  base  in  memory  rather  thar.  on  disk  and 
have  the  element  reports  output  to  the  Display  Group  via  the  LAN 
rather  than  to  magnetic  tape. 

The  more  difficult  task  for  the  Simulation  Group  will  be  to  make 
the  simulation  interactive.  The  Simulation  Group  must  be  made  to 
respond  to  the  vectoring  and  net  management  messages  formulated 
and  transmitted  by  the  Display  Group.  Even  these  changes  would 
be  straightforward  if  the  positional  changes  were  made  to  be 
instantaneous.  With  instantaneous  changes,  it  would  almost  be  as 
simple  as  inserting  the  new  number  into  the  Simulation  Group's 
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data  base.  The  problem  with  that  is  that  aircraft  don't  make 
instantaneous  changes  in  speed,  heading,  altitude, and  other 
flight  parameters.  Consequently,  instantaneous  changes  would 
produce  an  adverse  effect  on  the  ATALARS  algorithms  as  they  are 
both  time  and  value  sensitive.  Timing  of  messages  is  as 
important  as  their  content,  so  the  responses  programmed  into  the 
Simulation  Group  will  have  to  closely  emulate  the  characteristics 
of  the  simulated  aircraft.  Figure  10  depicts  the  architecture  of 
the  EJSE  as  modified  for  the  ATALARS  proof  of  concept 
demonstration . 

A  scenario  for  the  ATALARS  demonstration  would  be  initially  set 
up  with  a  number  of  elements  each  flying  in  a  specified  direction 
and  each  having  a  specified  start  time  and  reporting  recurrence 
rate.  Each  element  would  have  a  mission  briefing  on  file  in  the 
Display  Group.  The  Simulation  Group  would  start  creating 
position  reports  on  the  basis  of  this  information.  These 
position  reports  would  be  transmitted  to  the  Display  Group  in  the 
form  of  JTIDS  PPLI  messages.  The  Display  Group  would  process  the 
messages  received  such  that  the  Ground  Control  Unit  data  base 
would  be  updated.  Using  this  data  base  information  as  well  as 
the  airfield  status  information  and  the  aircraft  flight 
characteristics  built  into  the  system  as  inputs,  the  Display 
Group  would  cycle  through  its  ATALARS  algorithms  generating 
vectoring  and  net  management  commands  which  it  would  transmit 
over  the  LAN  to  the  Simulation  Group.  These  messages  would 
adhere  to  the  protocols  of  the  JTIDS  TIDP.  The  Simulation  Group, 
upon  receipt  of  these  messages,  would  modify  the  trajectory  or 
reporting  rate  of  the  appropriate  element  using  data  base 
maintained  flight  characteristics  such  as  turn  radius,  rate  of 
altitude  change,  or  rate  of  speed  change.  This  process  would 
then  continue  until  all  elements  were  on  the  ground  or  the 
scenario  was  terminated. 

2.4  Scenario 

2.4.1  Introduction.  One  of  the  products  of  this  study  was  to  be 
a  demonstration  of  what  the  Phase  II  demonstration  on  the  EJSE 
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will  look  like.  It  would  show  the  tracks  of  aircraft  under 
simulated  ATALARS  control  complete  with  relevant  message  traffic. 

The  items  that  would  be  missing  would  be  functioning  algorithms 
in  the  Display  Group  and  functioning  responses  in  the  Simulation 
Group.  Even  without  these  features,  some  of  the  potential 
attributes  of  ATALARS,  such  as  the  elimination  of  voice 
communication  and  direct  surveillance,  can  easily  be  seen.  These 
features  make  the  ATALARS  demonstration  on  the  EJSE  different 
from  other  ATC  simulators. 

The  functions  shown  in  this  scenario  are  relatively  simple  and 
involve  a  limited  number  of  aircraft.  This  was  done  so  that  the 
viewer  could  concentrate  on  the  ATALARS  interaction  with  an 
aircraft  and  not  be  distracted  by  a  high  volume  of  activity.  In 
addition,  since  the  algorithms  will  be  relatively  expensive  to 
develop  and  implement,  only  a  small  number  of  them  will  be 
necessary  at  the  outset  to  start  the  proof  of  concept  in  Phase 
II.  The  condensed  script  for  the  scenario  can  be  found  in  Table 
VII.  It  will  be  a  useful  reference  for  anyone  who  views  the 
demonstration . 

2.4.2  Scenario  Description.  The  scenario  that  has  been 
developed  for  Phase  I  is  to  be  situated  in  the  4th  Allied 
Tactical  Air  Force  area  of  West  Germany,  since  ATALARS  is 
initially  intended  for  use  in  a  tactical  situation.  There  are 
ten  airfields  shown  (Baumholder,  Bitberg,  Buchel,  Frankfurt, 

Hahn,  Hanau,  Ramstein,  Sembach,  Spangdahlem  and  Weisbaden)  each 
with  different  runway  lengths  and  aircraft  service  capabilities. 
There  are  21  aircraft  in  the  scenario,  17  of  which  are  friendly 
and  four  are  East  German  hostiles.  No  tactical  interaction  with 
the  hostiles  will  take  place,  however. 

Of  the  friendly  aircraft,  16  are  ATALARS  (JTIDS)  equipped  and  one 
represents  transient  friendly  traffic  which  is  not  ATALARS  equipped. 
The  ATALARS  equipped  aircraft  consist  of  one  AWACS  E3A,  six 
transient  aircraft  and  a  mix  of  returning  F15's  and  F16's,  which, 
for  the  purpose  of  this  scenario,  have  differing  airfield 
requirements  such  that  all  aircraft  cannot  land  at  all  airfields. 
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SCRIPT  FOR  ATALARS  SCENARIO 

SCENARIO  NUMBER  5 
CARD  IMAGE  TAPE  1020 
TAPE  GENERATION  135 
NUMBER  OF  ELEMENTS  -  21 
DATE  -  13  JANUARY  1988 


ASSUMPTIONS : 

*  ALL  AIRCRAFT  AND  CONTROLLING  AGENCIES  (ATALARS,  AWACS,CRC, 
ETC.)  HAVE  BEEN  PREBRIEFED  ON  RECOVERY  BASES  FOR  MISSION 
AIRCRAFT.  THIS  MINIMIZES  NEED  FOR  VHR/UHF/ JTIDS  VOICE 
TRANSMISSIONS . 

*  AIRCRAFT  UNDER  ATALARS  CONTROL  ARE  JTIDS  EQUIPPED. 

*  BASIC  JTIDS  INFORMATION  EXCHANGE  IS  CONSIDERED  ADEQUATE  FOR 
NORMAL  CONTROL.  JTIDS  VOICE  WOULD  BE  AVAILABLE  FOR  SUPPLE¬ 
MENTAL  DATA  (NECESSARY  FOR  INFLIGHT  EMERGENCIES,  BATTLE 
DAMAGE ,  ETC .  )  . 

*  PLAYERS : 

TNSC’S  4001,  4002,  4201,  4202,  4203,  4204,  CROSSING 
TRAFFIC. 

TNSC’S  3601,3602,  2202,  (F-15’S  RECOVERING  AT  BITBURG  AB ) 

TNSC’S  5001,5002,  2201,  (F-16’S  RECOVERING  AT  HAHN  AB ) 

TNSC’S  7604,7606,  2203,  (F-15’S  RECOVERING  AT  RAMSTEIN  AB ) 

TNSC  2001,  AWACS  IN  ORBIT 

TNSC ’  6001,  6002,  6003,  6004,  EAST  GERMAN  HOSTILES 
TNSC  2100,  FRIENDLY  BEING  REPORTED  BY  AWACS,  NOT  UNDER 
ATALARS  CONTROL 

*  MAP  DEPICTS: 

WEST  GERMANY 

PRIMARY  AREA  OF  INTEREST  IS  4TH  ALLIED  TACTICAL  AIR  FORCE 
AREA 

MISSILE  ENGAGEMENT  ZONE 
MINIMUM  RISK  CORRIDOR 

FEBA  IS  CONSIDERED  TO  BE  THE  EAST  GERMAN/CZECH  BORDER 
SEMBACH  AB  ( TACC  LOCATED  AT  THIS  SITE) 

BITBURG  AB  (36  TFW  -  F-15’S) 

HAHN  AB  (50  TFW  -  F-16’S) 

RAMSTEIN  AB  ( F- 1 5 ’ S ,  F-16’S  AND  COMBAT  SUPPORT  BASE) 
FRANKFURT  AB  (FORWARD  RECOVERY  BASE  FOR  BATTLE  DAMAGE) 
SPANGDAHLEM  AG  (RUNWAY  ONLY  -  NO  SERVICES  ) 

WEI SBADEN  AB  (AWACS  BASE) 

BUCHEL  AB  (TURN  AROUND  CAPABILITY  ONLY  -  FUEL/OXYGEN) 

HANAU  AB  ( CRC  LOCATED  AT  THIS  SITE) 

BAUMHOLDER  AB  (USED  AS  RECOVERY  CAP  POT NT ) 
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000001 

000100 

000130 

000156 

000201 

000255 

000315 

000354 

000400 

000406 

000412 

000747 

000754 

001317 

001318 

001658 

001706 

001830 

001914 

002130 


ATALARS  CONTROL  -  CENTERED  IN  4TH  ATAF  AREA 


SCENARIO  BEGINS  WITH  CROSSING  TRAFFIC  ACTIVE  IN  THE  ATALARS 
CONTROL  AREA.  AWACS  IS  ON  STATION  AND  STARTS  ORBIT. 

SEVERAL  FRIENDLY  AND  HOSTILE  FIGHTERS  APPEAR  ENROUTE  TO 
RECOVERY  BASES. 

4201/4202  ON  COLLISION  COURSE  AT  32000  FEET. 

ATALARS  DIRECTS  4201  TO  DESCEND  TO  26000  FEET  USING  VECTOR 
MESSAGE. 

4201  BEGINS  DESCENT. 

4201  REACHES  26000. 

RETURNING  FRIENDLY/HOSTILE  FIGHTERS  CONTINUE  TO  APPEAR. 

HANDOFF  OF  2203  BY  AWACS  TO  ATALARS  USING  "CONTROLLING  UNIT 
CHANGE"  MESSAGE  OR  IJMS  "Cl-11  -AIRCRAFT  CONTROL"  MESSAGE. 

2203  CHANGES  ACTIVITY  FROM  CLOSE  AIR  SUPPORT  TO  RETURN  TO 
BASE. 

ATALARS  DIRECTS  4203  TO  CHANGE  HEADING  TO  180  TO  AVOID  COL¬ 
LISION  WITH  42C4  USING  "VECTOR"  MESSAGE. 

4203  CHANGES  HEADING  TO  180. 

ATALARS  DIRECTS  2203  TO  DESCEND  TO  20000  AT  400  KTS  WHILE 
VECTORING  TO  WEISBADEN. 

2203  BEGINS  DESCENT  TO  20000. 

ATALARS  DIRECTS  2203  TO  DESCEND  TO  3000  FEET  AT  220  KTS 
VECTOR  TOWARD  BAUMHOLDER. 

2203  BEGINS  DESCENT  TO  3000. 

ATALARS  DIRECTS  2201  TO  HEADING  OF  180  AT  2600  FEET. 

(VECTOR  MESSAGE).  VICINITY  OF  HAHN  AB . 

ATALARS  VECTORS  2203  TO  BASE  LEG  SOUTH  OF  BAUMHOLDER. 

ATALARS  RECEIVES  "AIRFIELD  STATUS"  MESSAGE  FROM  HAHN  IN¬ 
DICATING  FIELD  IS  CLOSED. 

ATALARS  DIVERTS  2201  TO  BUCHEL  AB  AT  2600  FEET. 

ATALARS  CLEARS  2201  TO  LAND  AT  BUCHEL  USING  EXPANDED  IJMS 
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002331 

002400 

002505 

003000 


VI -1  MESSAGE. 

2201  LANDS  AT  BUCHEL. 

ATALARS  CLEARS  2203  TO  LAND  AT  RAMSTEIN  AB  USING  VI -1 
MESSAGE. 

2203  LANDS  AT  RAMSTEIN. 

ALL  TRANSMISSIONS  CEASE.  END  OF  SCENARIO.... 
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The  scenario  begins  by  showing  two  collision  avoidance  situations. 
These  simulate  situations  where  ATALARS  notes  that  two  aircraft  are 
on  converging  courses  and  recommends  the  directions  to  be  given  by 
the  controller  to  prevent  their  colliding.  The  messages  are 
transmitted  to  the  aircraft  using  the  JTIDS  data  link.  It  should  be 
noted  that  the  information  on  the  position  of  the  aircraft  was 
net),  and  that  no  voice  communication  was  required. 

The  returning  aircraft  (the  F15's  and  F16's)  enter  the  area 
controlled  by  the  Ground  Control  Unit  through  a  minimum  risk 
corridor,  and  begin  to  proceed  to  their  bases.  For  clarity,  this 
scenario  will  focus  primarily  on  one  aircraft  as  it  returns  to 
Ramstein . 

AWACS  hands  off  the  aircraft  to  ATALARS  with  a  JTIDS  "Controlling 
Unit  Change",  or  IJMS  "Aircraft  Control"  message.  (Note:  these  two 
messages  are  not  presently  processed  by  the  EJSE,  but  they  will  be 
implemented  for  the  MCE  program. )  ATALARS  then  gives  the  aircraft 
a  series  of  vector  messages  that  provide  the  landing  approach  to 
Ramstein.  It  is  envisioned  that  the  ATALARS  data  base  will  contain, 
in  tabular  form,  the  information  found  on  the  Approach  Plates  for 
all  airfields  in  its  control  area.  When  the  flight  plan  for  a 
particular  aircraft  is  accessed  by  ATALARS,  it  will  show  the  primary 
and  alternate  fields  assigned.  Then,  when  ATALARS  has  taken  control 
and  the  aircraft  changes  its  activity  designation  to  "return  to 
base",  the  appropriate  Approach  Plate  data  will  be  called  up  and 
used  to  vector  the  aircraft  to  its  assigned  field.  The  pilot's 
acknowledgment  of  the  vectoring  messages  will  be  the  initial 
feedback  on  the  plane's  activity.  The  plane's  position  would  then 
be  tracked  automatically  to  assure  that  it  is  following  the  approach 
instructions,  and  ATALARS  will  provide  a  warning  to  the  controller 
if  the  aircraft  strays  too  far  from  its  assigned  path.  When  fully 
developed,  ATALARS  will  be  going  through  these  steps  for  all  of  its 
controlled  aircraft.  Therefore,  the  Ground  Control  Unit,  upon 
receipt  of  each  plane's  return  to  base  message,  will  analyze  its 
request  to  land  with  respect  to  all  previously  received  requests  and 
will  assign  the  aircraft  to  the  appropriate  place  in  the  landing 
queue  for  the  selected  airfield.  A  further  iteration  of  this 
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process  will  occur  if  emergency  conditions  are  reported  by  one  or 
more  aircraft,  such  as  low  fuel,  live  ordnance  on  board  or  battle 
damage.  Then  ATALARS  would  recommend  the  best  solutions  to  the 
problem  presented  by  the  aircraft  and,  at  the  same  time,  try  to 
minimize  the  impact  on  all  the  other  aircraft  under  its  control  so 
that  they  are  not  all  forced  to  change  their  approach  plans  and  timing. 

The  Ground  Control  Unit  will  continue  to  cycle  through  its  internal 
ATALARS  algorithms  providing  finer  and  finer  control  of  the  aircraft 
until  the  aircraft  are  finally  on  the  ground.  As  each  aircraft  gets 
closer  to  its  assigned  airfield,  the  communications  between  it  and 
the  Ground  Control  Unit  will  become  more  frequent,  thus  providing 
tighter  feedback  control.  This  preliminary  scenario  leaves  the 
message  recurrence  rate  at  a  constant  six  seconds,  but  varying  rates 
will  be  used  in  the  more  sophisticated  simulations  that  will  be 
developed  in  Phase  II.  This  scenario  also  assumes  that  the  landings 
will  be  under  Visual  Meteorological  Conditions  (VMC).  Under  more 
adverse  conditions,  ATALARS  will  have  to  rely  on  something  more 
accurate  than  JTIDS  alone  as  a  precision  landing  aid  from  the  time 
the  aircraft  reaches  Decision  Height  until  it  touches  down. 

Capabilities  would  include  such  items  as  an  interface  between  JTIDS 
and  GPS  or  a  portable  MLS  with  limited  range  and  capable  of  being 
easily  turned  off  when  not  in  use. 

The  final  activity  shown  in  the  scenario  is  a  diversion  of  a  plane 
intending  to  land  at  Hahn  when  the  Ground  Control  Unit  receives  an 
"airfield  status"  message  indicating  that  Hahn  is  temporarily 
unavailable.  The  aircraft  is  vectored  to  Buchel,  about  20  miles 
away,  at  low  altitude,  and  is  cleared  to  land  with  an  IJMS  "aircraft 
vectoring  and  close  control"  message.  When  the  simulation  is  more 
fully  developed  in  Phase  II,  the  operator/observer  will  be  permitted 
to  alter  the  status  of  one  or  more  of  the  airfields  in  real  time 
just  as  if  the  Ground  Control  Unit  had  received  notification  that 
the  airfield  had  been  destroyed  by  enemy  fire.  As  a  result  of  this 
status  change,  the  system  would  have  to  "instantaneously"  re¬ 
evaluate  the  total  situation,  and  then  re-assign  and  re-vector  all 
affected  aircraft  based  on  the  new  set  of  conditions.  Here  again, 
the  special  requirements  presented  by  the  aircraft  would  have  to  be 
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considered  while  at  the  same  time  trying  to  minimize  the  overall 
impact  on  all  the  aircraft  under  the  Ground  Control  Unit's  control. 

This  scenario,  which  is  a  simulation  of  the  proof  of  concept 
demonstration,  is  available  now  for  viewing.  It  demonstrates 
both  graphically  and  on  the  basis  of  message  traffic  what  the 
Phase  II  simulation  will  accomplish  when  the  Simulation  Group  is 
set  up  to  interactively  simulate  a  number  of  aircraft  and  the 
Display  Group  is  set  up  to  simulate  the  ATALARS  Ground  Control 
Unit. 
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3.0  PROPOSED  EFFORTS  FOR  PHASE  II 

3.1  Introduction 

The  overall  goal  of  ACSI's  Phase  II  effort  is  to  produce  a  proof 
of  concept  demonstration  for  the  GCU  portions  of  ATALARS.  The 
preceding  sections  have  provided  the  background  and  described  the 
activities  that  would  be  required  to  accomplish  that  objective. 

In  this  section,  ACSI  will  define  the  specific  activities 
required  and  their  sequence  of  accomplishment.  This  section  will 
conclude  with  a  description  of  optional  features  and  enhancements 
which  could  be  added  as  development  of  the  concept  progresses. 

3.2  Develop  /  Conduct  Demonstrations 

ACSI  will  use  the  EJSE  as  the  vehicle  for  the  ATALARS  Proof  of 
Concept  demonstration,  and  will  start  with  the  scenario 
developed  for  Phase  I.  The  system  for  the  demonstration  will  be 
developed  incrementally,  as  illustrated  in  figure  11.  As 
significant  portions  of  work  are  complete,  the  added  capabilities 
will  be  demonstrated.  The  final  demonstration  in  this  sequence 
would  serve  as  an  ATALARS  Proof  of  Concept  demonstration.  When 
the  proposed  modifications  are  complete,  the  EJSE  Display  Group 
will  have  become  a  model  for  the  ATC  function  of  the  ATALARS 
Ground  Control  Unit. 

3.3  Display  Group  Modifications 

3.3.1  Install  Algorithms.  The  principal  task  for  Phase  II  is  to 
install  in  the  EJSE  Display  Group  the  algorithms  described  in 
Section  2.1.  They  represent  the  first  increment  of  the 
comprehensive  set  of  ATC  algorithms  that  would  eventually  reside 
in  the  ATALARS  processor.  In  addition  to  the  algorithms 
themselves,  the  design  would  include  rules  for  their  sequencing 
and  frequency  of  processing  as  well  as  how  their  output  would  be 
treated.  The  methodologies  employed  for  implementing  the 
algorithms  would  be  consistent  with  AI /Expert  System  practice. 
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FIGURE  11 
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This  is  because  it  is  expected  that  ATALARS  will  evolve  as  an  AI 
based  system.  Development  costs  would  preclude  a  rigorous  AI 
(LISP)  implementation  of  the  algorithms  in  Phase  II,  primarily 
because  the  EJSE's  current  JTIDS  message  handling  capabilities 
would  be  impacted.  However,  the  next  stage  in  development  would 
include  adding  a  separate  LISP  based  algorithm  processor  to  the 
EJSE . 

3.3.2  Message  Generation.  The  next  step  is  to  establish 
automatic  message  generation  routines  in  the  Display  Group.  This 
module  will  become  the  interface  between  the  ATALARS  Processor 
and  the  controlled  aircraft,  real  or  simulated.  In  response  to  a 
command,  either  from  the  EJSE  operator  of  from  the  ATALARS 
processor,  the  message  generator  will  construct  the  desired  JTIDS 
message  and  transmit  it.  It  would  also  include  an  optional  mode 
of  operation  where,  if  selected,  the  message  would  be  displayed 
for  EJSE  operator  review  and  transmitted  upon  his  release.  The 
additions  will  include  automating  the  composition  and  release  of 
JTIDS  command  messages,  which  are  presently  accomplished  by  a 
series  of  operator  interactions  with  menus  shown  on  the  Disply 
Function  Panel. 

3.3.3  ATALARS  Database.  The  existing  EJSE  Display  Group 
contains  database  functions  that  support  the  various  DP 
activities.  It  handles  static  files,  such  as  map  displays,  as 
well  as  dynamic  files,  such  as  trajectory  and  addressed  message 
data.  ACSI  would  use  these  functions  as  the  starting  point  to 
develop  the  ATALARS  Data  Base  functions  that  will  receive,  store 
and  provide  the  information  necessary  to  support  the  ATALARS 
algorithms,  and  to  assure  that  the  right  information  is  kept  and 
maintained.  Development  would  begin  with  the  data  elements  shown 
in  Table  VIII. 

3.4  Simulation  Group  Modification 

The  Simulation  Group  of  the  EJSE  must  be  made  interactive  ;_o 
permit  use  of  the  EJSE  for  a  Proof  of  Concept  demonstration. 
Specifically,  the  Simulation  Group  must  be  able  to  cause  a 
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TABLE  VIII 

ATALARS  DATABASE 
FOR 

PROOF  OF  CONCEPT  DEMONSTRATION 

Static  Files 

Approach  Plate  Information 

-  4  Airfields 

-  2  Runways/Airfield 

Flight  Characteristics 

-  F-15 

-  F-16 

-  Fuel  Burn  Rate  vs  Speed  &  Altitude 

-  Rates  of  Turn 

-  Rate  of  Ascent/Descent 

Separation  Requirements 
Dynami c  Files 

Flight  Plan/Mission  Briefing 

-  Route/Timing 

-  Controlling  Unit  Changes 

-  Primary  Recover  Field 

-  Alternate  Recover  Field 

Aircraft  PPLI 

-  Position 

-  Altitude 

-  Speed 

-  Heading 

-  Track  Number 

Aircraft  Status 

-  Fuel  Remaining 

Airfield  Status 

-  Open/Closed 

-  Runway  in  Use 

-  Landing  Queue 
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simulated  aircraft  to  receive  and  respond  to  an  addressed  message 
without  intervention  by  the  EJSE  operator.  For  example,  if  the 
EJSE  operator  initiates  a  vector  message  from  the  Display  Group 
to  a  specified  simulated  element  telling  it  to  change  course,  the 
operator  would  see  the  acknowledgment  and  subsequent  course 
change  by  that  element  without  further  interaction  with  the  EJSE. 
In  addition  to  the  logic  required  to  respond  to  messages,  a 
database  of  performance  characteristics  (such  as  rates  of  turn, 
climb,  descent,  acceleration  and  deceleration)  of  each  simulated 
aircraft  will  be  created. 

The  Simulation  Tape  Generation  (STG)  function  of  the  existing 
Modular  Control  Equipment  (MCE)  Baseline  EJSE  would  be  used 
without  modification  to  generate  a  scenario  Data  Base  Generation 
(DBG)  data  base  on  disk.  The  Simulation  Processor  (SP)  would  be 
modified  to  read  this  DBG  data  base  into  its  memory  in  a  pre¬ 
start  mode.  This  will  serve  as  the  starting  point  for  the 
demonstration  scenario. 

Next,  the  SP  would  be  modified  to  include  a  function  analogous  to 
the  existing  Tape  Generation  function,  but  would  send  PPLI  and 
Track  messages  to  the  Display  Processor  (DP)  in  real  time. 
Finally,  the  SP  would  be  modified  to  accept  command  messages  sent 
to  it  by  the  DP  and  to  respond  to  them  as  follows: 

o  Run  the  DBG  database  for  the  affected  element(s) 
through  a  function  similar  to  DBG  for  the  new 
parameters . 

o  Rearrange  events  in  the  simulation  as  necessary. 

o  Provide  for  smooth  turns  and  trajectory  changes. 

o  Send  out  the  resulting  PPLI  and  Track  messages  based  on 
the  changes  to  the  element  profiles. 

Modifications  to  the  SP  for  the  proof  of  concept  demonstration 
would  be  accommodated  to  the  following  extent: 

o  Only  selected  JTIDS  messages  and  fields  will  be 
implemented . 

o  There  will  be  no  print  function  at  the  SP  (not 
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required  for  interactive  simulation). 

o  A  maximum  of  ten  messages  per  second  will  be  sent  to 
the  LAN  by  the  SP  in  the  mode. 

o  The  SP  will  be  set  up  initially  to  handle  not  more  than 
30  JTIDS  elements  interactively. 

3 . 5  Technical  Report 

In  addition  to  the  demonstrations,  ACSI  will  prepare  interim  and 
final  technical  reports.  The  reports  will  cover  the  activities 
described  above,  with  their  actual  outcomes.  The  reports  will 
also  provide  an  assessment  of  the  aspects  of  the  ATALARS  concept 
covered  in  the  study.  The  final  report  will  contain  a  proposed 
work  plan  for  the  next  stage  in  the  development  of  ATALARS. 

3.6  Additional  Features 

There  are  several  directions  in  which  investigations  could 
proceed  after  the  Proof  of  Concept  demonstration.  The  potential 
extensions  tend  to  fall  into  groups. 

3.6.1  Algorithm  Additions.  The  first  group  consists  of 
additions  to  the  set  of  algorithms.  It  is  likely  that  each  of 
the  algorithms  created  will  have  places  where  additional 
operational  contingencies  can  be  addressed.  One  or  more  of  the 
algorithms  would  be  selected  for  review  and  further  expansion  in 
the  ATALARS  processor. 

3.6.2  Scenario  Additions.  Another  group  would  be  additions  to 
the  scenario.  More  controlled  aircraft  could  be  added,  providing 
the  capability  to  refine  estimates  of  the  volume  of  processing 
and  message  traffic  required  to  support  ATALARS.  One  or  more 
helicopters  could  be  added,  to  highlight  the  differences  in 
control  requirements.  Interaction  with  friendly  SAM  batteries 
would  serve  to  highlight  the  interoperability  features. 

3.6.3  Presentation  Enhancements.  The  last  group  of  features 
which  would  enhance  presentations  of  the  Proof  of  Concept 
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Demonstration.  By  setting  up  a  second  display  and  creating  an 
appropriate  window,  the  cockpit  display  could  be  shown  next  to 
the  ground  controller  display.  This  would  give  a  good  picture  of 
the  interaction  between  the  pilot  and  controller.  The  EJSE  could 
also  be  modified  so  that  fuel  remaining  and  other  status 
parameters  relevant  to  ATC  could  be  shown  in  the  tabular  display. 
This  capability  would  help  an  observer  see  when  a  change  in  a 
flight  parameter  precipitates  a  recommendation  for  change 
resulting  from  one  of  the  algorithms.  Finally,  ACSI  could  set  up 
the  EJSE  and  provide  support  for  a  demonstration  of  the  ATALARS 
concept  using  live  JTIDS  platforms. 

3.6.4  Artificial  Intelligence  Enhancements.  As  part  of  the 
transition  from  Phase  II  to  Phase  III,  a  powerful  PC  based  tool 
should  be  created  to  be  used  to  develop  and  demonstrate  the  AI 
portions  of  the  concept.  It  would  handle  some  of  the  ATC 
algorithms,  and  show  simulated  tracks  and  map  data,  but  would  not 
be  able  to  process  JTIDS  messages  or  model  the  GCU  man-machine 
interface  like  the  EJSE.  It  would  consist  of  a  state  of  the  art 
32  bit  microprocessor  (such  as  Intel  80386  or  Motorola  68020  or 
68030)  based  microcomputer  with  the  added  capability  to  handle 
LISP  programs.  Early  in  Phase  III,  or  after  the  proof  of  concept 
demonstration  in  Phase  II,  this  system  could  be  connected  to  the 
EJSE's  Display  Group  as  a  first  step  in  developing  the  GCU 
architecture.  This  would  allow  the  ATC  algorithm  processing,  or 
AI  functions  for  ATC,  to  be  handled  as  a  single  piece  of  a 
distributed  processing  environment. 
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5 . 0  GLOSSARY 

ACK 
ACS  I 
AGL 
AI 
AIM 

ATALARS 

ATA 

ATC 

AWACS 

CAS 

CRC 

C3 

DBMS 

DG 

DH 

EAC 

EJSE 

EMCON 

ESD 

FAF 

FAR 

FEBA 

FL 

FLIP 

FLOT 

GCU 

GPS 

IAF 

IAP 

IFF 

IFR 

I JMS 

JTIDS 


Acknowledge  (receipt  of  a  message) 
Analysis  and  Computer  Systems,  Inc. 
Above  Ground  Level 
Artificial  Intelligence 
Airman's  Information  Manual 
Automated  Tactical  Aircraft  Launch  and 
Recovery  System 
Airport  Traffic  Area 
Air  Traffic  Control 

Airborne  Warning  and  Control  System 
Close  Air  Support 
Combat  Reporting  Center 
Command,  Control,  Communications 
Data  Base  Management  System 
Display  Group 
Decision  Height 
Expected  Approach  Clearance 
Enhanced  JTIDS  System  Exerciser 
Emission  Control 

Electronic  Systems  Division  (of  Air 
Force  Systems  Command) 

Final  Approach  Fix 
Federal  Aviation  Regulations 
Forward  Edge  of  Battle  Area 
Flight  Level  (feet  xlOO) 

Flight  Information  Publications 
Forward  Line  of  Own  Troops 
Ground  Control  Unit 
Global  Positioning  System 
Initial  Approach  Fix 
Instrument  Approach  Procedures 
Identification  Friend  or  Foe 
Instrument  Flight  Rules 
Interim  JTIDS  Message  Set 
Joint  Tactical  Information  Distribution 
System 
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L/D  Max 

LAN 

MAP 

MCE 

MLS 

MOA 

MRC 

MSG 

MSL 

PPLI 

POS 

RPV 

SAM 

SBIR 

SG 

SIF 

TACS 

TADIL 

TCA 

TDMA 

TDZ 

TG 

TIDP 

TOA 

VFR 

VMC 

Vho 

Vso 


GLOSSARY  -  (Cont'd) 

Maximum  Lift/Drag 
Local  Area  Network 
Missed  Approach  Point 
Modular  Control  Equipment 
Microwave  Landing  System 
Military  Operations  Area 
Minimum  Risk  Corridor 
Message 
Mean  Sea  Level 

Precise  Participant  Location  & 
Identification 

Preliminary  Operational  Scenarios 
Remotely  Piloted  Vehicle 
Surface  to  Air  Missile 
Small  Business  Innovation  Research 
Simulation  Group 

Selective  Identification  Feature 
Tactical  Air  Control  Systems 
Tactical  Data  Information  Link 
Terminal  Control  Area 
Time  Division  Multiple  Access 
Touchdown  Zone 
Terminal  Group 

Technical  Interface  Design  Plan 

Time  of  Arrival 

Visual  Flight  Rules 

Visual  Meteorological  Conditions 

Maximum  Speed 

Stall  Speed 
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